Legacy System Migration FAQ: Answers to Questions Engineering Teams Actually Ask

Legacy system migrations generate a consistent set of questions from engineering teams, regardless of industry or technology stack. This FAQ answers the ones that come up most often — with direct answers, not hedged non-answers.

"How long will a legacy migration actually take?"

Longer than the first estimate. This is nearly universal. The first estimate is based on what is known about the system. The migration surfaces what was not known — undocumented edge cases, data quality problems, implicit dependencies, features that were assumed to be simple and turned out not to be.

A more reliable heuristic: take your initial estimate and multiply it by 1.5 to 2.5, then plan milestones that deliver value along the way so that if the project runs long, you have already shipped improvements rather than nothing.

For an incremental migration (strangler pattern), a typical mid-size system runs twelve to twenty-four months. For a big-bang rewrite of the same system, plan eighteen to forty-eight months and a much higher risk of the project not completing.

"Can we migrate without any downtime?"

For most systems, yes — but it requires deliberate engineering, not just fast execution. Zero-downtime migration depends on:

• Incremental traffic shifting via a facade layer (for application changes)
• Change data capture or dual-write patterns (for database changes)
• Expand-contract schema migrations that add new structures before removing old ones
• A tested cutover procedure with a defined rollback path

The moment you hear someone say the migration requires a maintenance window of more than a few minutes, ask why. In most cases, a zero-downtime approach exists and the maintenance window reflects a choice about engineering complexity, not a technical inevitability.

"What should we migrate first?"

Start with the piece that is lowest-risk and most clearly bounded — not the most painful piece, and not the most important piece. The first extraction is how the team learns the migration pattern. Do it on something where a mistake is recoverable and the blast radius is small.

Good first candidates: reporting services, notification delivery, background batch jobs, admin-only workflows.

Poor first candidates: payment processing, authentication, anything on the critical path for the core user experience.

"Do we need to migrate everything, or can we leave some parts in the legacy system?"

You can leave parts in the legacy system indefinitely, with caveats. The strangler pattern explicitly accounts for this — you migrate what makes sense to migrate and leave what does not. If a piece of the legacy system is stable, low-maintenance, and unlikely to need changes, there may be no business case to migrate it.

The risk of partial migration is dependency management. If the legacy component interacts with the new system, those interactions need to be kept stable. If the legacy component needs changes at the same time as the new system, the coupling complicates both. Document which legacy components are intentionally left in place and why, so that future engineers understand the decision rather than discovering it as an unexplained artifact.

"How do we handle data that is being written during the migration?"

This is the central challenge of live database migration. The standard approaches are:

Dual write: The application writes to both the legacy and new databases simultaneously for the duration of the migration. Reads come from the legacy database until the new one is validated, then reads shift to the new database.

Change Data Capture (CDC): A tool reads the source database's transaction log and streams every change to the target in near-real-time. The application does not need to be modified. The target database stays current until the cutover moment.

Event-driven sync: For systems with an event bus, domain events that update the legacy database also update the new service's database. This works best when the architecture already has event infrastructure.

The right choice depends on your existing architecture. CDC is usually the cleanest approach for database-to-database migration. Dual write is more appropriate when the data model is changing significantly.

## "What happens if the migration fails mid-way?"

This is why rollback planning is as important as migration planning. A well-designed migration has defined rollback points throughout — moments where the migration can be reversed with bounded impact. The further you are through the migration when you discover a problem, the more expensive the rollback.

The minimum viable rollback plan for any migration phase:

• A defined trigger condition (what determines that a rollback is needed)
• A documented step-by-step procedure for executing the rollback
• An estimate of how long the rollback takes
• A clear statement of what data state results from the rollback

Never enter a cutover window without a tested rollback procedure.

"Should we migrate or rewrite?"

Migration (incremental, using strangler pattern) and rewrite are not opposites — the strangler pattern is a form of incremental rewrite. The real question is: should this be incremental or big-bang?

Almost always, incremental. The exceptions are systems so small that the migration apparatus costs more than a clean rewrite, or systems so tightly coupled that no seam can be found to insert a facade layer.

For large systems, the incremental approach is almost always the right choice, regardless of how appealing a clean slate sounds.

"How do we keep the team motivated through a multi-year migration?"

Ship things. Migrations that deliver value throughout the process — each extracted service is an improvement the team can point to — are more sustainable than migrations where nothing ships until the end. Structure the work so that each phase has a visible outcome.

Also: be honest about scope. Teams lose motivation when they discover that the migration is larger than they were told. Setting accurate expectations at the start, including about timeline uncertainty, builds more trust than optimistic promises that slip repeatedly.

"When should we not migrate?"

When the cost of migration exceeds the cost of continued operation over the relevant time horizon. Some legacy systems are stable, rarely changed, and cheap to operate. If engineering is not regularly blocked by the system, and it is not a security or compliance liability, the business case for migration may not exist.

Also: when a third-party product covers the capability adequately. If you are considering migrating a custom CRM, check whether a modern CRM product fits your needs before committing to a migration project.

---

If you have a specific legacy migration question that is not answered here, or you want to talk through whether a migration makes sense for your system, get in touch with the Clixo team.