Migration style
Incremental strangler by capability rather than a big-bang rewrite.
Why. Risk and value are spread across releases.
Trade-off. A long period of running two systems.
Integration and multi-application · Modernisation
Legacy system modernisation with the strangler fig pattern, APIs and RPA
Replace a legacy system one capability at a time. A routing facade sends each request to the old or new implementation, anti-corruption layers protect the new design and RPA covers the gaps until APIs exist.
A reference architecture from EITSAA, not a named client system. Service limits, prices and product features change, so confirm current details before you commit to a design.
- ACSC Essential Eight
- Australian Privacy Principles
- SA ISMF supplier expectations
Architecture
- People and clients
- AI and ML
- Compute and containers
- Messaging, events and workflow
- SaaS and business systems
- Databases and data
- Security and identity
- Monitoring, audit and analytics
- Request or data flow
- Asynchronous or optional
- Boundary: region, account, network or trust zone
Request and data flow
All traffic goes through one facade that owns the URL space and authentication. Users see no difference.
Capabilities already rebuilt are routed to the new service, controlled by feature flags and percentage rollouts.
Everything else passes through to the legacy system via an anti-corruption layer.
The layer translates between the legacy model and the new domain model, so legacy quirks never leak into new code.
Where the legacy system has no API, RPA bots operate the legacy UI as a temporary adapter. The bot is a bridge, not a destination.
Change data capture streams legacy database changes into the new platform during the transition.
The new service receives synchronised data, so both systems stay consistent until the legacy capability is retired.
Components and why they were chosen
| Component | What it does | Why this choice |
|---|---|---|
| Routing facade (API Gateway, Front Door, NGINX) | Splits traffic between old and new. | Strangler pattern needs a single control point. |
| Feature flags (AWS AppConfig, LaunchDarkly) | Gradual rollout and instant rollback. | Safe migrations. |
| Anti-corruption layer | Translates legacy models. | Protects the new design from the old one. |
| New services | Rebuilt capabilities, a vertical slice at a time. | Value arrives early rather than after a three-year rewrite. |
| CDC (AWS DMS, Debezium, Fabric mirroring) | Streams legacy data changes. | Avoids dual writes. |
| RPA (UiPath, Power Automate Desktop) | Automates legacy screens. | Fast gap filler. Brittle if used permanently. |
| Parallel run and reconciliation tooling | Compares old and new outputs. | Evidence before cutover. |
| Decommissioning plan | Archive, retire and remove access. | Savings only arrive when the old system is turned off. |
Design decisions and trade-offs
Data
CDC and a clear owner per entity during transition, avoid dual writes.
Why. Dual writes diverge.
Trade-off. Synchronisation latency.
RPA
Tactical with a retirement date.
Why. Quick wins without re-platforming.
Trade-off. Maintenance when the legacy UI changes.
Sequence
Start with a low-risk, high-visibility capability.
Why. Prove the pattern and build confidence.
Trade-off. The hardest part comes later.
Well-architected pillars
Security
Facade enforces modern authentication in front of legacy systems that lack it. Isolate the legacy network.
Reliability
Instant rollback by routing, and parallel runs before cutover.
Performance
Cache read-heavy legacy responses in the layer.
Cost optimisation
Temporary double running cost. Track the decommissioning date as a financial target.
Operational excellence
Migration backlog by capability, with a visible burn-down.
Sustainability
Retiring old infrastructure is the largest benefit.
Network, identity and data
Networking
Legacy systems sit in a restricted segment reached only from the anti-corruption layer and CDC over private links. No direct user access remains once routing is in place.
Identity and least privilege
The facade adds SSO and MFA in front of the legacy application, mapping modern identities to legacy accounts through a controlled, audited service account.
Data and encryption
Reconcile counts and checksums regularly. Retain legacy data per records obligations and archive before decommissioning. Mask personal data in test copies.
Security and compliance mapping
| Control | How this design addresses it |
|---|---|
| Multi-factor authentication | Applied at the facade even if the legacy app cannot. Essential Eight. |
| Patch applications | Reduce exposure by isolating unpatchable legacy and retiring it. Essential Eight. |
| Records management | Archive and retention plan before decommissioning. |
Mappings show how the design supports each control. They are not certifications, and EITSAA does not claim IRAP assessment or compliance for any reference architecture.
Failure modes, targets and scaling
- Target RTOMinutes through routing rollback
- Target RPOSeconds to minutes for CDC
- Scaling and limitsConstrained by the legacy system. Protect it with caching and rate limits.
| Failure mode | Mitigation |
|---|---|
| Data divergence between old and new | CDC with reconciliation reports and a single owner per entity. |
| Rollout causes errors | Feature flag rollback in seconds. |
| RPA breaks on a legacy UI change | Monitoring, bot tests and a retirement date. |
| Migration stalls half-way | Backlog governed by outcomes and decommission milestones. |
Observability and runbooks
- Percentage of traffic on the new platform by capability.
- Reconciliation differences by entity.
- Legacy error and latency dashboards used as the baseline.
Cost drivers and levers
Parallel running, integration build and licences.
- Decommission early.
- Reduce RPA scope with APIs.
- Reuse the anti-corruption layer.
Implementation and fit
Phased approach
- Map capabilities and dependencies, choose the first slice.
- Introduce the facade with 100 percent pass-through.
- Migrate slices with flags and parallel runs.
- Retire the legacy system and archive data.
Anti-patterns to avoid
- Big-bang rewrite.
- Dual writes.
- Permanent RPA.
- No decommission date.
When to use it
- Business-critical legacy systems that cannot stop.
- Systems with poor or no APIs.
When not to
- Small systems that can be replaced in one release.
- Legacy with no clear boundaries.
More in integration and multi-application
Partners
B2B file and EDI exchange with partners and suppliers
Secure, auditable exchange of orders, invoices and reports with partners that still send files: managed SFTP, validation, translation, acknowledgements and monitoring that proves nothing was lost.
AWS and Azure
API-led integration hub with an event bus, API gateway and iPaaS
A small number of governed APIs and an event backbone in front of many systems, so each application integrates once with the hub instead of with every other application.
Web, mobile and back office
Multi-channel API platform with a portal over several back-end apps
Web, mobile and staff back-office experiences on one API platform. A backend-for-frontend per channel and a micro-frontend portal let several applications look like one product without becoming one codebase.
Related insights
Discuss this architecture
Tell us your systems, constraints and timeline. We reply within one business day, and the initial conversation is free.