Cloud Migration Roadmap: A Step-by-Step Plan

The board wants the company “in the cloud by Q3.” Finance needs a number it can defend. Operations wants to be certain the cutover will not disrupt customers on Monday morning or leave controllers scrambling at month-end.

What these teams often receive instead is a technical plan with a loosely defined finish line. It may explain the infrastructure work in detail, but it does not answer the practical questions leaders need to put the migration on a calendar: Which workloads move first? What does each wave need to prove? When should the next round of funding be released?

Without that sequence, a cloud migration can easily turn into a long technical exercise with an uncertain end date. With it, the migration becomes a program the business can actually manage.

Before approving significant spend, a practical cloud migration roadmap should answer three questions:

What business capability will improve after this wave?
How will the business know the cutover worked?
Who owns the go / no-go decision, and what evidence will they use?

Answer those questions for every phase, and the roadmap becomes far more than an aspiration. It becomes something the CEO, COO, and board can steer with confidence.

The Six Migration Approaches

The right approach is the one that supports the intended business outcome, not necessarily the one that sounds the most modern.

Approach	Business Outcome	When It Fits
Rehost (lift and shift)	Move to the public cloud quickly with minimal disruption	Legacy systems that need to move without being redesigned
Replatform	Gain some of the benefits of modernization without rebuilding the application	Applications that can benefit from PaaS or managed services
Refactor / re-architect	Improve long-term performance, scalability, and cloud-native capability	Core systems that justify a larger modernization investment
Repurchase	Replace a custom system with SaaS	A SaaS product can meet 80% or more of the requirements
Retire / decommission	Eliminate unnecessary workloads	Systems with no active users or functionality that exists elsewhere
Retain	Keep a workload on-premises	Regulatory, latency, or cost constraints make migration impractical

Rehosting is often the right choice when speed matters most. Refactoring is easier to justify when a system supports an important revenue process and has already reached its scalability limits. Re-architecting into microservices makes sense for platforms the company expects to own, extend, and rely on for years.

In practice, most portfolios use a combination of approaches. A company might rehost low-risk workloads to build momentum, replatform mid-tier systems on AWS, Microsoft Azure, or GCP, and reserve full refactoring for the applications where the investment will materially improve the business. Multi-cloud and hybrid cloud models may also be appropriate when data residency, disaster recovery, or operational requirements make a single cloud service provider too limiting.

And “retain” should remain a legitimate option. Sometimes leaving a workload where it is represents sound judgment, not indecision.

Timeline, Budget, and Risk at a Glance

The ranges below offer a useful starting point for comparing approaches before committing to a broader cloud migration strategy.

Approach	Typical Timeline	Budget Range	Key Risks	Where Fixed-Fee Reduces Exposure
Rehost	Weeks to months	Lower	Compatibility, performance	Scope and acceptance criteria can be defined upfront
Replatform	Months	Medium	Data migration, integration	Production rehearsals can reduce cutover risk
Refactor	Months	Medium to high	Unforeseen complexity	Prototypes and phased acceptance gates can contain risk
Repurchase	Weeks to months	Variable, depending on licensing	Feature gaps, data fit	Integrations and cutover can be scoped separately
Retire	Weeks	Low	Data retention, compliance	Contracted deliverables can close the remaining risk
Retain	Ongoing	Operational	Opportunity cost	Not typically suited to fixed-fee delivery

Fixed-fee builds at unosquare start at $100K, are scoped before code is written, and typically take 8–12 weeks. On a fixed-fee engagement, if delivery takes longer than planned, the additional cost is ours, not yours.

Put the First Wave on the Board Calendar Before Scaling Spend

Once the overall approach is clear, define what the first funded wave needs to prove. Name the workload, agree on cutover criteria the business will recognize, and set the price for that specific slice of work.

See how unosquare’s fixed-fee scoping process works. Discovery takes one week and produces a working prototype rather than another proposal. Scope and price are locked in week two, before the build begins.

What Board-Ready Proof Actually Looks Like

A useful roadmap becomes real when leaders can picture the first migration wave, not just the delivery methodology behind it.

Consider a monthly management reporting package that still relies on an on-premises data store. Or take a customer portal that cannot go offline during cutover. Either can make a strong first wave because it is visible to leadership, has a clear business owner, and can be evaluated without asking executives to interpret architecture diagrams.

For a wave like that, “done” might mean:

Controllers can produce the standard month-end reporting pack from the new environment on the scheduled close day, with totals matching the agreed reconciliation checks.
Customer-facing pages remain within the agreed performance range during peak hours after cutover.
The rollback path has been rehearsed in staging, and the business owner has reviewed the evidence before signing the go / no-go decision.
Availability, data integrity, and recovery targets are written in the same terms used in existing operating reviews.

These criteria shift the conversation away from “we moved the servers” and toward outcomes the business cares about: “we protected the reporting calendar” or “we maintained the customer experience.” That is the kind of evidence a board can use.

unosquare starts building that evidence early. Leadership sees a working prototype in week one, before the full wave is funded. Design and price are locked in week two, and the build is measured against the same cutover criteria throughout the engagement.

A Board-Ready Phase Sequence

The sequence below can serve as the backbone of the migration calendar. Each phase produces a signed deliverable before the next one begins; progress is earned rather than assumed.

Phase 0: Confirm readiness before committing the budget

Four prerequisites should be in place before migration spend is approved.

Prerequisite	What It Requires
Executive sponsorship	One named executive with the authority to approve or reject deliverables
Application and data center inventory	A complete inventory of what will move, its dependencies, and its compliance boundaries
Compliance posture	HIPAA, PCI, GDPR, or FINRA requirements mapped to specific workloads and data flows
Risk register	Known migration risks documented with named mitigation owners and rollback plans

If any of these pieces is missing, the plan does not yet account for the company’s full operating risk.

Phase 1: Prove the first wave

Before expanding the program, test the approach on a specific, named workload. The phase should produce:

A working prototype of the first migration wave
A documented acceptance test plan with clear pass / fail criteria the business owner can understand
A cutover rehearsal report showing what was tested, what failed, and how the issues were resolved

All three are necessary. Together, they form the go / no-go gate for the funded build.

Phase 2: Lock the design, scope, and price

Two documents should be signed before the build begins:

A line-item Statement of Work with an explicit out-of-scope appendix
An acceptance test matrix with a binary yes / no test for every deliverable

Payments should be tied to accepted artifacts rather than estimated calendar progress. That keeps funding connected to outcomes the board can verify.

Phase 3: Move in waves the business can absorb

Every wave should include:

A documented rollback plan with recovery steps that have been rehearsed, not merely written down
Go / no-go approval from the named executive owner before the wave enters production
Evidence from a staging environment that reflects production conditions, including load-balancing and auto-scaling behavior under realistic demand

The executive owner should hold rollback authority for every wave. Put that authority in writing so the team knows exactly who can stop or reverse a cutover when pressure is high.

Phase 4: Complete cutover, hypercare, and handoff

Final payment should be released only after the agreed hypercare KPIs have been met. This keeps the vendor focused on stability during the first operating week, not simply on reaching go-live.

The handoff should include:

AWS, Azure, or GCP repository and pipeline access transferred to the internal team
Step-by-step operational recovery instructions
Credentials and account access verified by operations
A KPI baseline captured at cutover, including availability, data integrity, and mean time to recovery

Build and deployment automation, along with scripts for setting up the environment, should also transfer at this stage. Your team needs to be able to operate what the company has paid for.

Phase 5: Measure results after migration

The 30 / 60 / 90-day period after cutover is where the company validates whether the investment delivered what was promised.

KPI	What to Measure
System availability	Performance against the contractual baseline
Data integrity	Migrated data compared with the source
Mean time to recovery	Recovery performance during incident scenarios, aligned with business continuity requirements
IT infrastructure cost	Spend compared with the pre-migration baseline, including reserved instances and compute optimization

Post-cutover cost reviews should compare reserved instances and other compute commitments with the pre-migration baseline. If the agreed KPIs are not met within the warranty period, the contract should define specific remedies, such as SLA credits, remediation days, or both.

What Makes the Calendar Enforceable

A roadmap becomes much more reliable when four provisions are built into the engagement from the start.

1. Lock the scope and price

A firm fixed-price Statement of Work should include a complete list of deliverables, an explicit out-of-scope appendix, and milestone payments tied to accepted work. Fixed-fee programs often become variable-cost engagements when the scope is left open to interpretation.

2. Define ownership of IP and operations

At handoff, the company should receive access to the code repository, ownership of all build and deployment automation, credentials and account access, and clear operating guides. The vendor should retain no rights to the work it created. If the internal team cannot operate the system independently, the handoff is not finished.

3. Rehearse rollback and cutover

Require at least one complete rollback exercise in staging before production cutover. The resulting report should document how closely staging matched production, which tests were run, what passed or failed, and who approved the result.

4. Tie exit rights and payments to performance

Define clear exit triggers. For example, if a named acceptance milestone is missed by more than an agreed number of days, the company should have a clean way to end the engagement. Keeping final payment tied to verified hypercare KPIs also helps preserve accountability after go-live.

Governance: Who Signs Off and When

Governance keeps the migration calendar grounded in real decisions. Each sign-off controls payment and authorizes the next phase of work.

Phase Gate	Accountable Owner	What Triggers Next Phase
Phase 0 complete	Executive Sponsor	Readiness checklist signed
Prototype accepted	Executive Sponsor + Legal	Rehearsal report and acceptance test plan approved
Contract signed	Executive Sponsor + Legal	Line-item SOW and acceptance matrix signed
Each wave accepted	Named Business Owner	Wave rehearsal report and go / no-go signed
Cutover accepted	Executive Sponsor	Hypercare KPIs verified and signed
Final payment released	Finance + Executive Sponsor	All acceptance artifacts on file

Each row represents a real control point. If a phase does not have a named owner, it can move forward without clear authorization, and that is usually where schedules begin to drift.

Compliance: What the Roadmap Must Capture

In regulated environments, such as cloud migration for financial institutions, compliance requirements need to appear in the acceptance criteria. They cannot remain a side conversation or an assumption.

Regulation	Required Contract Element
HIPAA	Data residency clause, encryption standard, audit trail for data migration
PCI	Scope boundary documentation, access controls, network segmentation verification
GDPR	Data processing agreement, deletion and portability procedures, breach notification terms
FINRA	Data retention policy, immutable audit trail, disaster recovery and business continuity testing

The acceptance test matrix should include compliance validation alongside functional testing. A migration that performs correctly but fails a HIPAA review is not complete. That distinction needs to be explicit before the work begins.

Is Fixed-Fee Right for Your Migration?

Fixed-fee, locked-scope delivery works well when the desired outcome is specific enough for everyone to agree on what “done” means. Many migration waves meet that standard, but not all of them do.

Fixed-fee is likely a good fit when:

The company has a firm deadline, such as a board commitment, regulatory date, or contract renewal
The internal team has limited capacity to manage an open-ended vendor engagement
Code, data, and infrastructure ownership must belong to the company from day one
The scope is already defined: the team knows what is moving and where it will go

It may be better to pause when:

The target cloud architecture is still being explored
Phase 0 prerequisites are incomplete
Business requirements continue to change

The test is straightforward: can the desired outcome be described clearly enough to write a binary acceptance test? If so, fixed-fee may be appropriate. If not, start with a tightly scoped prototype before committing to the full program.

Start With a Prototype. Define the Scope and Price From There.

Week one produces a working prototype of the migration wave in your environment. In week two, the scope, price, and acceptance criteria are locked before the production build begins. See how it works. There is no commitment required to complete Discovery.

Frequently Asked Questions

How is scope locked before code starts, and who owns the risk of scope creep?

Scope is locked before the build through a line-item Statement of Work signed at the end of the architecture phase. The SOW lists every deliverable, while an explicit out-of-scope appendix clarifies what is not included. Acceptance criteria are binary: each deliverable either passes or it does not.

In a properly structured fixed-fee engagement, the vendor carries the risk associated with delivering the agreed scope. If a new requirement falls outside the SOW, it should become a separately scoped and priced change order rather than being quietly absorbed into the original project.

How does a fixed-fee model protect us if the project takes longer than expected?

The fixed fee places a ceiling on the cost of delivering the agreed scope, even if the work takes longer than planned. That is the central difference between fixed-fee and time-and-materials billing.

This protection depends on having a clear scope and measurable acceptance criteria before the build starts. The more precisely the outcome is defined upfront, the more meaningful the cost ceiling becomes.

What do we receive in week one of Discovery?

You receive a working prototype: a functioning deliverable built in your environment that shows whether the proposed approach is viable. It is not simply a slide deck or a requirements document.

Discovery also produces mapped workflows, identified dependencies, and a documented acceptance test plan. Together, these give the company a practical go / no-go point before it commits to the full build.

What do we own at the end of the engagement: code, data, and infrastructure?

You own the code repository, data, build and deployment automation, credentials, and cloud infrastructure accounts on AWS, Azure, or GCP. The vendor retains no rights, charges no licensing fees, and creates no ongoing dependency.

The handoff is complete only after the operations team has verified access to every system, reviewed the recovery instructions, and confirmed that it can run the platform independently.

How do you handle security and compliance in regulated industries?

Compliance requirements are translated into contract clauses and acceptance criteria. If the migration needs to meet HIPAA, PCI, GDPR, or FINRA requirements, those obligations are mapped to specific deliverables, including data residency documentation, encryption standards, audit trail verification, and access-control sign-offs.

unosquare has delivered production software for financial services, healthcare, and other regulated industries. Projects can be built to undergo penetration testing and meet SOC 2 requirements before launch.

References

Microsoft. (2025). Select your cloud migration strategies. Microsoft Learn. https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/plan/select-cloud-migration-strategy
Orban, S. (2016). 6 strategies for migrating applications to the cloud. AWS Executive in Residence Blog. https://aws.amazon.com/blogs/enterprise-strategy/6-strategies-for-migrating-applications-to-the-cloud/
Google. (n.d.). Migrate to Google Cloud: Get started. Google Cloud Architecture Center. https://docs.cloud.google.com/architecture/migration-to-gcp-getting-started
Flexera. (2026, March 18). Flexera 2026 State of the Cloud Report: The convergence of cloud and value. Flexera Blog. https://www.flexera.com/blog/finops/flexera-2026-state-of-the-cloud-report-the-convergence-of-cloud-and-value/
Amazon Web Services. (n.d.). About the migration strategies. AWS Prescriptive Guidance. https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-guide/migration-strategies.html
Jansen, W., & Grance, T. (2011). Guidelines on security and privacy in public cloud computing (NIST SP 800-144). National Institute of Standards and Technology. https://csrc.nist.gov/pubs/sp/800/144/final
Microsoft. (2025). Migration wave planning. Microsoft Learn. https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/migrate/migration-wave-planning
Microsoft. (2026). Plan your migration. Microsoft Learn. https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/migrate/plan-migration
Amazon Web Services. (n.d.). Reserved Instances for Amazon EC2 overview. Amazon EC2 User Guide. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-reserved-instances.html

Our Editorial Standards

unosquare is committed to publishing accurate, well-researched information about B2B software delivery. Our editorial team reviews content for accuracy and draws on reputable sources, including industry analysts, technology standards bodies, academic institutions, peer-reviewed research, and established enterprise software providers. References are checked for relevance and accessibility at the time of publication.

We work hard to keep everything accurate, but information can change as delivery models, pricing benchmarks, and technology standards evolve. If you notice an error or something that appears outdated, please contact us so our team can review it.

Important Disclaimer

The information on this website is provided for general informational and educational purposes. It is not professional legal, financial, or technical implementation advice. Before making decisions about software investments, vendor selection, or delivery models, consult qualified technology advisors, legal counsel, or other appropriate professionals. unosquare assumes no liability for actions taken based on the information presented on this site.