Replatform or Automate Around It

Your legacy system isn't going anywhere soon. The question is whether you work around it or replace it — and the answer depends on details most replatforming pitches conveniently skip.

---

What Does "Replatform" Actually Mean Here?

Replatforming means moving your core workload to a different runtime, database, or architecture. It's not a lift-and-shift. Lift-and-shift is just migration. Replatforming implies rethinking data models, service boundaries, and often the deployment model alongside the move.

Automating around a system means building integrations, orchestration layers, and transformation pipelines that let the legacy core keep running while new capabilities sit on top of or alongside it. You're not touching the core. You're wrapping it.

These are genuinely different bets. Choosing between them isn't a technical question alone — it's an operational and financial one too.

When Is Automating Around the Legacy System the Right Call?

The clearest case for automation-first is when the legacy system holds state or domain logic that would take years to reconstruct. ERP systems are a good example. SAP or Oracle EBS instances often contain 10–15 years of business rules, patched into customisations that nobody fully documented. Replacing that in 18 months is possible only if you're willing to accept significant regression risk.

In these situations, a well-designed integration layer buys you time and optionality. You expose the legacy system's data via an API gateway, standardise the event schema, and let new microservices consume it cleanly. The legacy system's internal messiness is contained behind an adapter.

This approach has a real cost, though. You're now maintaining two systems simultaneously. Every schema change in the legacy system can break your adapters. If the legacy system's vendor drops support, you're accelerating toward a hard deadline anyway. Automation-first delays replatforming; it doesn't cancel it.

When Adapters Become a Liability

If your legacy system's data model is fundamentally misaligned with your current domain model, adapters accumulate complexity fast. A field called CUST_TYP_CD that maps to six different meanings depending on a context flag buried in a related table is not something you can abstract cleanly without writing increasingly brittle transformation logic.

At some point, you're spending more engineering time maintaining the wrapper than you would have spent replatforming. That tipping point is often earlier than teams expect, typically within 18–24 months of the first adapter going live.

How Do You Know the Legacy System Is Actually the Bottleneck?

This is worth testing before you commit to either path.

Run a structured bottleneck analysis. Identify the three or four business capabilities that are most constrained. Trace each one: is the constraint in the legacy system's data model, its throughput, its deployment frequency, or the organisation's understanding of it?

Sometimes the constraint is organisational. The legacy system could support what you need, but nobody on the current team knows how to extend it safely. That's a different problem — a documentation and knowledge-transfer problem — and replatforming won't solve it if the same team builds the replacement.

Sometimes the constraint is genuine throughput. If your PostgreSQL 9.6 instance (out of community support since November 2021) is running full-table scans on a 500 GB table because the schema can't be indexed properly without a model change, that's a technical constraint the current system cannot solve without surgery.

The distinction matters because automation-first fixes organisational constraints poorly and technical constraints only partially.

Replatforming: What the Estimates Always Get Wrong

Most replatforming estimates are wrong in the same direction — they undercount the data migration effort and overcount the feature-build effort.

Cost Area	Common Estimate Error	Reality
Data migration	10–15% of total effort	Often 30–40%
Integration testing	Included in QA	Usually a separate workstream
Cutover planning	1–2 sprints	3–6 sprints for live systems
Legacy decommission	Not costed	Non-trivial, often 2–4 months
Staff retraining	Not costed	Significant for ops teams

The other thing estimates miss is parallel running cost. During cutover, you'll run both systems simultaneously. For cloud-hosted workloads, that's a direct infrastructure cost. For licensed systems, you may hit licensing clauses that charge for both instances.

Plan for at least one month of parallel running minimum. Three is safer for any system handling financial transactions or regulated data.

Choosing a Migration Strategy

There are four patterns worth knowing:

• Strangler fig: New functionality is built on the new platform; legacy handles existing flows until each is migrated over. Low risk, long timeline.
• Big bang: Full cutover on a set date. High risk, faster timeline, appropriate only for smaller systems with well-understood data.
• Database-first: Migrate and modernise the data layer first, then move the application. Useful when the legacy app is thin and the database is the real complexity.
• Feature-flag-driven: Both platforms run; traffic is routed at the feature level. Requires solid observability and rollback capability.

Strangler fig is the default recommendation for systems above a certain complexity threshold, roughly speaking if the system has more than five internal integrations or three years of accumulated business logic.

What Does Good Automation-First Architecture Look Like?

If you decide to automate around the legacy system for now, the architecture decisions you make in the first six months will either extend your options or narrow them.

The most important decision is the event schema. Define it independently of the legacy system's internal model. Use a format like CloudEvents 1.0 or AsyncAPI-described schemas, and version them from day one. If your event schema mirrors the legacy system's tables, you've just moved the coupling one layer out.

The second decision is observability. Your adapter layer needs distributed tracing from the start. When something breaks at 2 AM, you need to know whether the failure is in the legacy system, the adapter, or the consuming service. Without tracing, debugging cross-system failures becomes archaeology.

The third decision is ownership. Somebody owns the adapter layer and is accountable for its health. If it's treated as shared infrastructure with no clear owner, it will degrade without anyone noticing until a production incident forces the conversation.

Conclusion

Neither path is universally correct. Automation-first is lower risk in the short term and higher risk if you let it run too long. Replatforming is expensive upfront and often underestimated, but it removes the ceiling.

The clearest next step is an honest bottleneck audit before committing to either. Map your top business constraints to their technical causes, estimate the adapter maintenance cost at 18 months out, and compare that against a realistic replatforming scope. That exercise usually makes the decision obvious.

If you'd like to work through that audit with an engineering team that has done this in both directions, reach out to the Sodio team.

FAQ

Is it always cheaper to automate around a legacy system than to replace it? In the first 12–18 months, usually yes. Adapter work is scoped and bounded. Replatforming has long tails. After that window, accumulated adapter complexity and dual-system maintenance costs often cross the replatforming cost curve. The break-even depends heavily on how unstable the legacy system's schema is.

What's the biggest technical risk with the strangler fig pattern? The most common failure mode is never fully completing the migration. Teams migrate 80% of functionality, the legacy system lingers for the remaining 20%, and two years later you're still running both systems. You need a hard decommission date set before the migration begins, with organisational commitment behind it.

Can you replatform a database without replatforming the application? Yes, and sometimes it's the right sequence. If the application logic is sound but the database engine is the constraint — for example, moving from MySQL 5.7 to PostgreSQL 15 to access partitioning or better JSONB support — you can migrate the data layer first. Expect a significant testing effort on stored procedures and any ORM-generated queries.

How do you prevent the adapter layer from becoming its own legacy system? Version your event schemas from day one, write adapter logic as stateless functions where possible, and treat the adapters as temporary by design. Document the intended decommission condition explicitly: "This adapter is retired when Feature X is live on the new platform." Without that condition stated upfront, adapters tend to become permanent.

When is replatforming clearly the wrong choice? When the business domain itself is changing significantly. If you're replatforming a CRM while simultaneously rethinking how your sales process works, you'll be building to a moving target. Stabilise the domain model first, then replatform. Doing both simultaneously is one of the more reliable ways to run over budget and timeline.

Have a project in mind? Contact Sodio Technologies to discuss your requirements and explore the right technology solution for your business.