What Real Discovery Looks Like

The single biggest predictor of migration success is the quality of discovery. Underinvest in discovery and you will pay for it ten times over during cutover. The discipline uses automated tools — AWS Application Discovery Service, Azure Migrate, Google Cloud Migrate, or Cloudamize — to inventory every server, application, dependency, and data flow across the estate. Each workload receives migration complexity scoring and business-priority ranking. Hidden dependencies — the file share three teams forgot existed, the cron job nobody documented, the licensing agreement tied to a specific MAC address — surface during discovery, not at 2am on cutover Saturday.

The deliverable is a migration readiness assessment that includes the inventory, the 6Rs classification, the wave plan with sequencing rationale, the network and identity migration design, and a risk register with mitigation owners. If a vendor proposes a migration without producing this artefact, they are selling a hope, not a plan.

Database Migration: The Hard Part

Servers replicate cleanly. Databases do not. Database migration is where most cloud migration projects discover they were under-scoped. Modern providers use AWS DMS, Azure Database Migration Service, or native replication to migrate Oracle, SQL Server, PostgreSQL, MySQL, and MongoDB with schema conversion, data validation, and performance benchmarking pre- and post-migration. Change data capture enables near-zero-downtime cutover for production databases.

The discipline that distinguishes serious providers: rehearsal cutovers run end-to-end before the production switch. The team migrates a clone of the production database to the target, runs the application against it, validates query performance, identifies stored procedures that misbehave on the new platform, and documents fixes. By the time production cutover happens, every surprise has already happened in rehearsal. Cutover windows shrink to under two hours because the work has been done already.

Network and Identity: The Other Hard Part

Cloud networking is a different paradigm from on-premises networking, and identity federation is where security incidents happen during migration. Real providers handle network and identity migration in parallel with workload migration, not as an afterthought. The work covers VPC or VNet architecture design, AWS Direct Connect or Azure ExpressRoute or GCP Cloud Interconnect for hybrid connectivity, VPN tunnels as backup, DNS migration with a documented cutover plan, and identity federation with Azure AD or AWS IAM Identity Center so users have seamless access from day one.

The mistake to avoid is treating network and identity as "we'll figure that out near the cutover date." Both have long lead times — Direct Connect provisioning can take weeks, identity federation requires testing across applications — and both block production cutover if they slip.

Pricing Patterns in Real RFPs

Cloud migration is usually priced as a fixed-fee project plus optional managed-services attach. The shape of the market today looks roughly like this.

The pricing trap is comparing total project cost between providers without normalising scope. A vendor proposing $200K versus a vendor proposing $400K may be selling the same project at different completeness. Specifically, the cheaper proposal frequently omits post-migration optimisation, leaving the customer with a rehosted estate running at 30-40% over optimal cost — savings the optimisation phase was supposed to capture.

How Migration Vendors Actually Differ

Across real RFPs, six dimensions consistently distinguish strong vendors from weak ones.

1. Methodology depth — does the vendor use AWS MAP, Azure Migrate, or Google Cloud Migrate frameworks with documented playbooks for every workload type, or are they improvising on the customer's environment?
2. Cutover discipline — are continuous replication and rehearsal cutovers standard practice, or is the cutover plan "we'll do our best on the night"?
3. End-to-end ownership — does the vendor stay through post-migration optimisation, or do they hand off at cutover and leave the customer to figure out cloud operations?
4. Cost commitment — does the vendor commit to a target infrastructure cost in writing, with an obligation to optimise until it is met?
5. Cross-cloud capability — can the vendor handle AWS-to-Azure or Azure-to-GCP migrations, or are they single-cloud only?
6. Industry references — does the vendor have references from customers in your industry with comparable estate size?

For cloud-to-cloud migrations specifically, additional planning is needed for service mapping (RDS to Cloud SQL, S3 to Blob Storage), identity migration, and network architecture redesign. A vendor whose entire portfolio is on-prem-to-AWS is not a multi-cloud migration partner regardless of marketing claims.

The reference-checking discipline matters more than most evaluation teams give it credit for. When you talk to a reference customer, ask three questions specifically: how did the vendor handle the surprise that wasn't in the original plan, how aggressive was post-migration cost optimisation, and would the customer hire the same vendor again for a second migration. The first question reveals operational maturity, the second reveals economic alignment, and the third is the single best predictor of whether you are about to sign with the right partner.

How Opsio Helps

Opsio's cloud migration services deliver the full discipline above as managed engagements: automated discovery, 6Rs classification, wave-based execution with rehearsal cutovers, network and identity migration in parallel, and 4-8 weeks of post-migration optimisation that captures the cloud economics the original business case promised. We have delivered 200+ migrations under AWS MAP and Azure Migrate frameworks, with sub-2-hour cutover windows on most workloads and zero data-loss incidents. For platform-specific work, we run AWS cloud migration consulting on Amazon-bound projects and Azure migration service on Microsoft-bound projects, and our replatform cloud migration practice handles the lift-and-optimise workloads that are most enterprises' sweet spot. Engagements typically begin with a fixed-fee assessment that produces the wave plan before any infrastructure moves, with an optional cloud adoption service programme attached for the operating-model work post-cutover.