Many teams still rely on BizTalk. You can modernise safely by inventorying what you have, targeting Azure services that match each responsibility, and migrating in phases.
1) Inventory what exists
- Applications, orchestrations, maps, schemas, trading partners, adapters, schedules, SFTP/FTP, batch jobs.
- Volumes and SLAs (messages/day, peak times, failure patterns).
2) Target architecture on Azure
- APIs: Azure API Management (mediation, throttling, policies).
- Workflows: Logic Apps (Standard) for orchestration.
- Messaging: Service Bus queues/topics for decoupling.
- Compute: Functions/.NET services for custom logic.
- Observability: Application Insights, distributed tracing, dashboards and alerts.
- Secrets: Key Vault; per-environment config.
3) Pilot, then phase
- Strangler pattern: carve out one interface, mirror traffic, validate, then cut over.
- Data & partners: handle partner certificates/keys and schema compatibility early.
- Non-functional needs: throughput tests, back-pressure, retry/idempotency.
4) Operate from day one
- Run-books, dashboards, and clear on-call expectations.
- Cost guard-rails (per-connector budgets, message caps, alerts).
Common pitfalls
- Lifting BizTalk designs "as-is" without embracing async and API mediation.
- Skipping partner testing or schema validation until late.
- Under-investing in observability and cost controls.
Takeaway: Inventory → target → pilot → phase. Keep business risk low while steadily reducing legacy footprint.