Cloud Migration Phrases: Lift-and-Shift, Refactoring & Cutover Language
5 exercises on cloud migration vocabulary. Choose the most natural and professional option.
0 / 5 completed
1 / 5
You're presenting the first phase of a cloud migration where you move existing systems without redesigning them. What do you call this approach?
"Lift-and-shift" is the industry-standard term for migrating systems to cloud without re-architecting them. Using this term in planning discussions signals expertise and sets the right expectations. Real examples: "We're doing a lift-and-shift first, then we'll evaluate what to refactor"; "Lift-and-shift gets us out of the data centre fast — optimisation is phase two." Options B-D are accurate descriptions but avoid the standard terminology, making them sound less professional in a migration planning context.
2 / 5
You need to communicate when the production switch will happen. What do you say?
"The cutover window is..." is the correct migration term for the planned period when traffic is switched from old to new system. Including the exact time range and mentioning a war room signals operational maturity. Real examples: "Cutover window: Sunday 02:00-06:00 UTC, rollback trigger at 04:30 if not stable"; "The cutover window is Friday night — attendance mandatory for core platform team." Options A/B/D lack the precision and professional vocabulary expected in migration planning.
3 / 5
During transition, data must be written to both the old and new system simultaneously. What's the technical term and how do you explain it?
"Dual-write" is the precise migration pattern where writes go to two systems simultaneously to ensure data consistency during switchover. Explaining it clearly ("every write goes to both") shows you understand the implementation, not just the term. Real examples: "Dual-write for 72 hours, then we flip reads to the new DB and monitor"; "Dual-write phase: both Postgres and the new Cassandra cluster receive every event." Options A-C describe the concept but avoid the term "dual-write," which is what engineers expect to hear.
4 / 5
You need to reassure stakeholders that you have a plan if the migration fails. What do you say?
"Rollback plan is..." is the standard way to communicate your recovery strategy in migration contexts. It names the mechanism (repoint DNS), the affected system (old cluster), and gives a time estimate (15 minutes). This level of specificity builds stakeholder confidence. Real examples: "Rollback plan: flip the load balancer back to on-prem, ETA 10 minutes"; "Rollback plan is documented in the runbook — step-by-step, tested last Thursday." Options A/C/D are vague and don't show you've engineered the rollback.
5 / 5
Users will not notice any disruption during the migration. How do you communicate this?
"The migration will be transparent to users" is the standard stakeholder communication phrase for a zero-downtime migration. "Transparent" in this context means invisible/seamless, and pairing it with "no downtime or data loss" addresses the two things stakeholders care about most. Real examples: "Migration will be transparent to users — zero downtime, reads/writes continue uninterrupted"; "Transparent to users: our SLA of 99.9% uptime will be maintained through the cutover." Options B/C/D avoid the professional term "transparent" and are less precise.