Inventory and assess first, then pick a treatment per component rather than one strategy for everything: rehost what is stable, replatform where a managed service removes toil, refactor only where there is a clear payoff, and retire whatever nobody uses. Sequence by risk, starting with something low stakes to prove the pipeline. Plan data migration and cutover carefully, since that is the part with real downtime, and keep a rollback path.
Why interviewers ask this
Migration questions test planning and pragmatism. The interviewer wants to hear discovery before design, per component decisions instead of a religious position on lift and shift versus rewrite, and a realistic view of data movement, which is where migrations slip. They also listen for how you sequence work to build confidence and how you would prove the migration succeeded.
How to structure your answer
- Start with inventory, dependencies and a per component decision.
- Name the treatment options and when each applies.
- Sequence by risk and land an easy win first.
- Detail the data migration and cutover with a rollback path.
Example answer
The first phase is discovery, and it always takes longer than anyone budgets. What is running, what talks to what, what the actual utilization is, who owns it, and what the licensing and compliance constraints are. Out of that comes a decision per component rather than one strategy for the whole estate. Stable things that work get rehosted with minimal change, because the value is in getting out of the data center, not in rewriting. Things where a managed service removes a pile of operational work, usually databases and queues, get replatformed. Refactoring I reserve for components where there is a genuine business case, because it is the slowest and riskiest option. And a surprising amount gets retired, since every estate has servers nobody has needed for years. Then sequence by risk: an internal, low traffic service first so we exercise the networking, the pipeline and the runbook where mistakes are cheap. Data is the hard part, so replicate continuously ahead of time, run in parallel, and keep the on premises system live and rollback ready for a couple of weeks after cutover.
Walking into this interview soon? GhostPilot listens to your live call, spots the question the moment it is asked, and puts a structured answer on your screen in real time. Try it on your next mock, or grab a $29 Session Pass, no subscription, for the real thing.
See how it worksFollow-up questions to expect
- How would you move a multi terabyte database with a short cutover window?
- How do you handle an application with a hard coded dependency on a local file share?
- How would you prove the migration was successful?
Related cloud engineer questions
Your interviewer will ask their own version of this. Paste your actual job description into the free Question Predictor and get the 20 questions that role is most likely to ask, with what each one is really probing.
Predict my questions