Migration Planning Interviews

The Question Behind the Question

When an interviewer asks you to plan a migration, they are not testing whether you know the strangler fig pattern. Every Principal candidate knows the strangler fig pattern. They are testing whether you can manage a multi-quarter, multi-team effort that touches every part of the engineering organization while keeping the business running.

The candidates who fail this interview are the ones who treat it like a system design problem. The candidates who pass are the ones who treat it like a program management problem with deep technical constraints.

Open with Questions, Not Architecture

Before you draw a single box on the whiteboard, ask about the current system. What is the architecture? What are the traffic patterns? Where is the data, and how much of it is there? What is the team structure? What are the business constraints (downtime budget, compliance requirements, active feature development)?

One question most candidates forget: "What has been tried before?" If the company already attempted this migration and failed, understanding why it failed is more valuable than any architectural diagram you could draw.

This scoping phase should take 3-5 minutes of your answer. It demonstrates that you understand migrations are context-dependent, and that a migration plan designed in the abstract is worthless.

Structuring Your Migration Answer

Present your approach in phases. A solid structure looks like this:

Phase 0: Discovery and Assessment. Map the current system. Identify dependencies. Measure baseline performance. Assess team skills. Build the business case. This phase often takes 4-6 weeks and candidates who skip it are proposing to solve a problem they do not yet understand.

Phase 1: Foundation. Set up the target environment. Establish CI/CD pipelines. Implement observability. Migrate one low-risk component as a proof of concept. The purpose of this phase is to validate your approach cheaply before committing the organization.

Phase 2: Incremental Migration. Move components in order of risk and dependency. Use the strangler fig pattern where applicable. Run old and new systems in parallel with traffic splitting. This is the longest phase and where most migrations stall, so discuss how you maintain momentum.

Phase 3: Cutover and Decommission. Final traffic switch. Monitor closely. Decommission old infrastructure only after a stability period. Resist pressure to decommission early because rolling back after decommission is enormously expensive.

Anti-Patterns in Candidate Answers

The architect who ignores people. "We will decompose the monolith along domain boundaries using DDD." Great. But who will do that decomposition? Does the team have microservices experience? If not, when do they learn? A migration plan that does not address skill gaps is a plan that will stall in Phase 2.

The optimist who forgets data. Application migration is the easy part. Data migration is where migrations go to die. Dual-write strategies, change data capture, data validation, handling schema differences between old and new systems, managing the cutover window when you switch the source of truth. If your answer treats data as an afterthought, the interviewer will probe until it hurts.

The perfectionist who cannot ship. Some candidates design a migration plan so thorough that it would take two years to execute. The business will not wait two years. Discuss how you would time-box each phase, define go/no-go criteria, and make the hard call about what is "good enough" to proceed.

The big-bang dreamer. "We will freeze feature development for a quarter and do the migration all at once." No production system with 10 million users can tolerate a feature freeze. And big-bang migrations fail at a much higher rate than incremental ones because you cannot test the full system until the very end. If something goes wrong, you have no intermediate state to fall back to.

The Risk Conversation

Interviewers will probe your risk awareness. For each phase, be ready to discuss what could go wrong and how you would handle it. Data inconsistency during dual-write periods. Performance degradation during traffic splitting. Team burnout on a multi-quarter migration. Scope creep from stakeholders who want to add features during the migration.

Name these risks before the interviewer asks about them. It shows you have done this before.

Organizational Considerations

Strong candidates discuss the human side. How do you keep the team motivated during a long migration that does not ship visible features? How do you train the team on new technologies? How do you communicate progress to leadership? How do you handle the parallel cost of running two systems? These questions separate Senior from Principal answers.