Legacy middleware migrations are among the most politically and technically complex projects in enterprise IT. The system is mission-critical, thoroughly undocumented, understood by two people who are thinking about retirement, and has accumulated 10 years of business logic that nobody fully understands but everyone depends on.
This is the story of migrating a manufacturing group's BizTalk Server 2013 environment to Symfony 6 / API Platform 3. The BizTalk instance handled 47 integration flows across SAP, 3 ERPs, a CRM, and a logistics platform, processing approximately 2 million transactions per month.
Phase 1: Discovery and Flow Inventory
The first four weeks were spent exclusively on discovery. We catalogued all 47 integration flows with: source system, target systems, data volumes, transformation logic, error handling behaviour, and business criticality. This produced the Migration Backlog — each flow as a story with complexity estimate and business impact score.
Critically, we found 11 flows that were effectively dead — they existed in BizTalk but were not actively used. These were decommissioned rather than migrated, immediately reducing scope by 23%. Finding these is only possible through thorough discovery; skipping this phase would have wasted significant migration effort.
The Strangler Fig Pattern
We used the strangler fig pattern: the new Symfony platform was deployed alongside BizTalk, not as a replacement. A lightweight routing layer (an nginx configuration managed as code) directed traffic for each flow to either BizTalk or the new platform based on a feature flag in Redis. This allowed incremental migration with instant rollback capability for any flow.
API Platform 3: The Right Tool for This Problem
API Platform 3 with Symfony 6 was chosen over alternatives (MuleSoft, Azure Integration Services, custom Node.js) for several reasons: the team already had Symfony expertise, the licence cost was zero, and API Platform's built-in OpenAPI generation meant every integration API was automatically documented — a significant improvement over BizTalk's non-existent documentation.
We implemented each integration flow as a dedicated Symfony service with its own Docker container, test suite, and deployment pipeline. This decomposition replaced a single monolithic BizTalk application with 36 focused services — easier to test, deploy, monitor, and debug independently.
- Invest 4 weeks in discovery — you will always find dead flows worth decommissioning
- The strangler fig pattern is non-negotiable for mission-critical middleware migration
- A routing layer with feature flags enables zero-risk incremental cutover
- Decompose the monolith: one service per integration flow, not one big replacement
- API Platform's auto-generated OpenAPI documentation pays for itself immediately