Your CFO has a migration slide open in the boardroom. The headline says the program is over budget and late. Application owners are arguing about dependencies, security is questioning the landing zone, and engineers are spending more time reconciling spreadsheets than improving products.
That situation exposes the central mistake in cloud programs. Cloud migration isn’t a one-way vote for public cloud. It’s a workload-placement and operating-model decision. Each application needs a destination, a migration pattern, a cost model, controls, and an owner who can run it after cutover.
A capable cloud migration consultancy helps you make those decisions before sunk cost becomes the strategy. It also tells you when to resize, pause, or reverse a move.
The Cloud Migration Decision You’re Actually Making
Consider a regulated enterprise with more than sixty workloads spread across legacy data centers and two hyperscalers. The board wants a recovery plan within thirty days. Some systems support revenue-producing products, others carry sensitive records, and several exist because nobody has proved what would break if they were retired.
The leadership team may describe the problem as “getting to the cloud.” That framing is too shallow. The primary question is where each workload should run, under which controls, at what cost, and with what recovery path. A public cloud region might suit an elastic customer-facing service, while a tightly coupled legacy platform may belong in a private environment or remain on-premises until its dependencies change.
The costs extend beyond infrastructure
A delayed migration creates more than infrastructure expense. It can expose the enterprise to audit findings, postpone product launches, consume engineering capacity, and damage confidence between technology and finance. Teams also face practical decommissioning work, including asset inventories, data retention, secure disposal, and evidence that old facilities were retired correctly. A useful reference for that operational side is the guide from Reworx Recycling on data center decommissioning.
The recovery plan should separate four decisions:
- Continue: Keep moving workloads whose economics, dependencies, and controls are sound.
- Rescope: Change the pattern, destination, or wave order for workloads carrying excessive risk.
- Pause: Stop a migration until missing evidence, such as dependency mapping or recovery testing, exists.
- Reverse: Return a workload to a more suitable operating model when cloud economics or constraints no longer work.
Practical rule: A consultancy earns its fee by improving decisions, not by increasing the number of workloads marked “migrated.”
The provider choice matters. You may need a specialist firm for the hardest portion of the portfolio, augmentation for an incumbent systems integrator, or an internal cloud center of excellence that owns the operating model. The right answer depends on capability gaps, governance maturity, workload complexity, and how much control you need to retain.
What a Cloud Migration Consultancy Does in 2026
The cloud migration services market has become a major global services category. One 2026 industry estimate values it at $19.28 billion and projects growth to $143.7 billion by 2035, implying more than 22% annual growth over that forecast period, as reported in this cloud migration statistics overview. That growth reflects demand for external help with application, data, and workload planning, execution, and ongoing operations.
The firms buying this expertise aren’t limited to technology companies. Regulated banks need controlled transitions and audit evidence. Healthcare systems need strong identity, data protection, and operational accountability. Media organizations may manage enormous archives with very different access patterns from transactional systems. Industrial companies often need consultants who understand SAP estates, plant connectivity, and the consequences of interrupting operational systems.
Three provider models
Hyperscaler Professional Services brings deep knowledge of one provider’s platform. It’s a sensible choice when the target architecture is already clear and the enterprise wants accelerated access to provider-native services. The trade-off is obvious: a provider-aligned team may have less incentive to recommend another destination.
Global systems integrators offer scale, industry coverage, and access to large delivery teams. They can coordinate complex programs, but you need to verify who will perform the architecture work. A strong proposal can still result in a junior-heavy delivery model.
Boutique migration specialists tend to be more hands-on with difficult workloads, platform engineering, application modernization, and cross-cloud decisions. They’re often a better fit when the enterprise needs candid technical judgment rather than a large staffing machine. For organizations building internal capability, it can also help to understand the responsibilities attached to a cloud migration specialist.
The dominant migration pattern remains lift-and-shift, which accounted for 38.3% in the cited industry research. Refactor and re-architect strategies are growing at 22.35% annually, showing that consultancies increasingly compete on both speed and technical depth.
A serious consultancy owns more than a migration schedule. Its deliverables should include:
- Portfolio assessment and TCO modeling: Identify what should move, what should change, and what should be retired.
- Landing-zone architecture: Define accounts or subscriptions, identity, network topology, logging, security controls, and guardrails.
- Application roadmaps: Connect replatforming or refactoring work to dependencies and business priorities.
- Migration-factory operations: Standardize tooling, runbooks, testing, wave governance, and rollback.
- FinOps and security baselines: Make cost allocation, policy enforcement, and risk visibility operational from the start.
- Post-cutover optimization: Tune utilization, performance, reliability, and ownership after production traffic arrives.
A body shop supplies people to tickets. A strategic consultancy supplies opinionated architects who challenge scope, reject unsafe sequencing, and make the client capable of operating the result.
How a Typical Engagement Unfolds
The first phase is discovery, not infrastructure provisioning. The consultancy inventories applications and data, rationalizes the portfolio, maps dependencies, interviews stakeholders, and builds a TCO model that finance can challenge and approve. The output should be a workload register with complexity, business criticality, dependency relationships, compliance needs, target placement, migration pattern, and cutover risk.
The first decision gate is simple. No workload enters a migration wave until its owner accepts the target state, its dependencies are understood, and its success criteria are written down. A consultancy that skips this gate is converting uncertainty into schedule risk.
Build the foundations before the factory starts
The landing zone comes next. That means establishing the multi-account or multi-subscription topology, identity boundaries, network connectivity, centralized logging, policy guardrails, backup expectations, and deployment standards before production workloads arrive. MITRE guidance recommends comparing the “As-Is” and “To-Be” governance models, documenting the new baseline, and controlling later changes through formal change control and periodic review in its cloud migration planning guidance.
Microsoft’s workload migration governance guidance identifies five control areas that belong in this foundation: cost management, security baseline, identity baseline, resource consistency, and deployment acceleration. That scope matters because governance isn’t merely a security checklist. It also determines whether teams can deploy consistently and explain what they spend.
The pilot should use a non-critical workload, but it must be representative enough to test the migration factory. The consultancy should validate tooling, infrastructure as code, data movement, observability, application testing, cutover communications, and rollback runbooks. The gate is evidence, not enthusiasm.
Move in waves, then transfer ownership
Wave sequencing should follow dependency and risk, not department politics. Each wave needs a cutover plan, a tested rollback path, a communications plan, validation criteria, and named approvers. During hypercare, the consultancy and internal team monitor reliability, performance, security signals, and cost together.
A sensible hypercare window lasts 30 to 90 days. By its end, ownership should transfer with working runbooks, dashboards, alert routes, access reviews, and a decision log. Teams looking for an engineering partner should assess whether the provider can support this full lifecycle through cloud migration engineering services, rather than treating go-live as the finish line.
Migration Patterns and the Trade-Offs Between Them
Pattern selection should happen at the workload level. A blanket “rehost everything” policy creates technical debt, while a blanket refactoring mandate turns a migration into an open-ended application rewrite.
The common choices have different purposes:
- Lift-and-shift, or rehost: Move the workload with limited application change. It can accelerate a data center exit, but it often preserves inefficient architecture and weak cloud economics.
- Replatform: Replace selected infrastructure components with managed equivalents, such as a managed database service or a platform-as-a-service runtime. This can improve operational efficiency without requiring a full redesign.
- Refactor: Re-architect the application to use cloud-native patterns. It offers the greatest capability gain, but it requires strong product ownership, testing discipline, and a longer investment horizon.
- Hybrid: Keep selected systems on-premises or in private infrastructure while moving suitable services to public cloud. This is often the right compromise for regulatory, latency, licensing, or integration constraints.
Migration Pattern Trade-Offs
| Pattern | Timeline | Cost Impact | Risk | Best For |
|---|---|---|---|---|
| Lift-and-shift | Fastest path to relocation | Can preserve inefficient spend | Technical debt and limited optimization | Data center exit, stable legacy workloads |
| Replatform | Moderate | Can reduce operational overhead | Moderate application and data compatibility risk | Databases and runtimes suited to managed services |
| Refactor | Longest | Highest initial investment, strongest long-term capability potential | High delivery and architecture risk | Strategic products that need scalability and faster evolution |
| Hybrid | Depends on workload grouping | Balances placement economics | Operational complexity across environments | Regulated, latency-sensitive, or tightly integrated systems |
The cited migration research reports lift-and-shift as the most common approach at 38.3%, while refactor and re-architect strategies are growing at 22.35% annually. Those figures don't mean refactoring is automatically correct. They show that the market is moving beyond relocation alone.
A consultancy should make the trade-off explicit. If an application has a near-term facility-exit deadline and limited strategic value, rehosting may be rational. If it blocks product growth, replatforming or refactoring may justify the investment. For tightly coupled legacy estates, a focused legacy system modernization approach can separate safe migration from necessary redesign.
How to Evaluate and Select the Right Consultancy
Start with accountability. Ask for the name of the architect who owns the target architecture, migration decisions, and escalation path. If the proposal describes a “resource pool” but doesn't identify accountable technical leadership, you're buying staffing rather than outcomes.
Test the operating model before signing
Use questions that force the consultancy to show working practices:
- Governance: Who approves target-state exceptions, and how are architecture decisions recorded?
- FinOps: Can the team demonstrate a cost-allocation model, tagging policy, budget alerts, and unit-cost reporting before contract signature?
- Compliance: Which HIPAA, PCI-DSS, FedRAMP, or GDPR-regulated workloads has the firm taken through audit? Can it identify the auditor and explain the evidence process?
- Delivery: Which engineers will perform the work, and how much of the engagement will senior architects personally deliver?
- Risk: What conditions would make the firm recommend pausing, resizing, or reversing a migration?
- References: Can the firm introduce a client that paused or rescoped an engagement midway?
The last question is particularly revealing. Marquee logos prove that a contract existed. A reference involving a difficult scope change shows whether the consultancy can handle disagreement without hiding risk or protecting its original plan.
Make the exit testable
Ownership must transfer as a designed outcome, not a hopeful assumption. Put the following into the statement of work:
- Infrastructure as code: Your team receives repositories, standards, pipeline access, and documentation.
- Operational runbooks: Internal operators can handle deployment, rollback, backup, incident response, and recovery testing.
- FinOps dashboards: Cost views are organized by workload, environment, product, and accountable owner.
- Security evidence: Control mappings, access reviews, logging configuration, and exception records are available to your auditors.
- Knowledge transfer: Internal staff participate in build and operation, rather than receiving a slide deck at the end.
The decisive question is whether your in-house team can run the platform after the consultancy leaves. Require a practical operating exercise, not a presentation. Have internal engineers execute a deployment, investigate an alert, trace a cost anomaly, and perform a rollback using the delivered assets.
When Migration Should Be Reversed or Resized
Public cloud is a deployment option, not a corporate ideology. Some workloads belong in public cloud. Others fit private cloud, colocation, or an existing data center because their cost profile, latency requirements, licensing model, or regulatory constraints don't match hyperscaler economics.
Recent industry coverage reports that 69% of organizations are considering moving workloads back from public cloud, while 35% have already done so. Another reported measure puts the share of workloads and data that had been repatriated at 21%. These figures come from the coverage of cloud repatriation trends. They don't prove that repatriation is right for every enterprise. They do prove that “once in cloud, always in cloud” is a poor governance principle.
Repatriation Triggers and Thresholds
| Trigger | Threshold | Likely Action |
|---|---|---|
| Cost overrun | Cloud spend materially exceeds the approved workload model | Recalculate utilization, architecture, commitments, and placement |
| Security or compliance pressure | Required controls or residency conditions cannot be sustained economically | Move to a compliant region, private environment, or on-premises platform |
| Integration friction | Network, data, or platform dependencies create persistent operational problems | Redesign the integration boundary or relocate the dependent workload |
| Predictable workload economics | Stable demand makes dedicated capacity more attractive | Compare private infrastructure, colocation, and cloud commitments |
| Performance constraint | The target environment cannot meet application requirements consistently | Test a lower-latency placement or redesign the service boundary |
Don't invent arbitrary thresholds and call them universal rules. Use workload-specific evidence: utilization, storage growth, egress, inter-environment traffic, licensing, support effort, latency, recovery requirements, and audit obligations.
The consultancy's role is to resize the operating model. That may mean moving only the database, retaining a private processing tier, consolidating environments, or returning the entire workload. Teams should also review cloud computing optimization practices after cutover, because a poor configuration can look like a placement problem.
Running a Successful Engagement and Measuring It
Migration governance becomes real when specific people own specific outcomes. Establish a joint steering committee that meets weekly during the first 90 days, appoint one accountable executive sponsor on the client side, and maintain a written RACI. Separate responsibility for cost overruns from responsibility for timeline slippage. The finance owner may control budget decisions, while the technology owner controls architecture and delivery sequencing.
Set measurement up in the first week. Go-live isn't a success metric. It is an event that should trigger a more demanding operating review.
Engagement Success Metrics and 30-Day Post-Cutover Milestones
| Metric or Milestone | Target / Threshold | Owner | Review Cadence |
|---|---|---|---|
| Burn rate versus forecast | Escalate when actual spend leaves the approved tolerance | Executive sponsor and finance lead | Weekly |
| RPO and RTO drill | Meet the workload's approved recovery objectives | Platform and application owners | Before cutover, then during recovery reviews |
| Defect escape rate | Escalate recurring production defects or failed validation gates | Quality lead and application owner | Per wave, then weekly in hypercare |
| User-visible latency | Remain within the application's approved performance baseline | SRE or operations lead | Continuous monitoring, weekly review |
| FinOps unit cost per workload | Explain material variance from the approved unit economics | FinOps owner and product owner | Weekly during hypercare, monthly afterward |
| First 30-day review | Decide whether to accelerate, stabilize, or reverse the workload | Steering committee | Day 30 |
Control the first month after cutover
A hypercare rota should identify who responds to application incidents, platform alerts, security findings, data issues, and cost anomalies. Keep a decision log that records assumptions, exceptions, approvals, and unresolved risks. Without it, teams repeat old debates and lose the context behind architecture choices.
The first thirty days should end with a cost-and-performance review. Compare actual resource use with the approved model, inspect latency and reliability against the baseline, validate recovery evidence, and review unresolved defects. Then make a deliberate decision:
- Accelerate when the migration factory is repeatable and the workload meets its operating criteria.
- Stabilize when the workload is functioning but cost, performance, or ownership remains unsettled.
- Reverse when evidence shows that the placement or operating model is wrong.
Post-migration optimization isn't a cosmetic cleanup. Flexera's 2025 state-of-cloud reporting says 84% of organizations struggle to manage cloud spend, while 87% use cost efficiency or savings as their top cloud-goal metric in the cited cloud spend findings. A separate migration study reported average project cost overruns of 18% and an average loss of $315,000 per platform migration project, with timeline overruns, burnout, security gaps, and tool sprawl among the causes, as summarized in the migration cost analysis.
Savings usually require 12 to 24 months of optimization, architecture changes, and ongoing FinOps, not a single cutover event. Choose a cloud migration consultancy that can stay accountable for those economics, transfer the operating capability to your team, and recommend reversal when the evidence demands it.
devPulse helps enterprises assess cloud readiness, design migration strategies, execute rehosting, replatforming, and re-architecting, and continue with performance and cost optimization after cutover. Visit devPulse to discuss a workload-by-workload migration plan that your engineering, finance, security, and operations teams can run.
