SaaS Platform Migration from Colocation to AWS — Engagement Archetype

This is a representative engagement archetype — not a disclosure of a specific client or past project. It describes the kind of work this practice is built to execute, the shape of a typical engagement in this category, and the outcomes such an engagement is scoped to deliver.

The situation this archetype addresses

A growth-stage SaaS company (roughly 100-250 employees, $15-35M ARR range) running on colocation infrastructure enters late-stage acquisition discussions. The buyer’s technical diligence flags the colocation hosting as a risk — absence of cloud-native operational maturity, concentration in physical facilities, dependencies on aging hardware approaching end-of-life.

The deal timeline is six to nine months. Leadership needs the infrastructure story to be defensible before closing: the migration to AWS needs to be substantially complete, operational procedures need to be cloud-native, and the documented environment needs to match what a buyer’s technical diligence will actually find.

The internal engineering team has deep product knowledge and some AWS experience at the component level, but has never run a full migration and does not have capacity to lead one while continuing to ship product.

This archetype shows up in growth-stage SaaS companies approaching strategic acquisition. It is a specific pattern, and the engagement that fits it is a specific shape.

How this engagement is scoped

We scope this archetype as a combined readiness assessment plus execution engagement. Given the typical timeline, readiness and early execution run in parallel rather than sequentially. Parallelism is a compression pattern we use only when timeline pressure is real and the client team can absorb the coordination overhead — we are transparent about that tradeoff during scoping.

Weeks one and two: Readiness. Inventory workloads across the colocation footprint (typical mid-market SaaS has fifty to one hundred). Map dependencies. Identify compliance constraints (SOC 2 maintenance during migration is non-negotiable for most SaaS in this segment). Produce a workload-by-workload disposition matrix — which are straightforward lift-and-shift, which need moderate re-platforming, which require meaningful refactoring, which are deferred.

Weeks three through eight: Landing zone and first wave. Design the AWS landing zone as infrastructure-as-code (account structure, networking, identity, logging, backup). Migrate the lift-and-shift workloads first to validate the landing zone in production.

Weeks nine through eighteen: Moderate-complexity workloads. Re-platforming engagement — for example, moving from VM-based on-prem to container-based on AWS ECS or EKS. Applied to the workloads that benefit from re-platforming without a full refactor.

Weeks nineteen through twenty-four: Complex refactors and cutover. Legacy components that require rework — session stores, authentication services, data replication patterns often land here. Core application platform cutover executed over a small number of planned maintenance windows.

Throughout, the client’s internal engineering team continues product feature work. Our team handles the migration work. Knowledge transfer happens continuously through code review, pair programming on complex refactors, and joint operational runbook authoring.

Target outcomes for this engagement archetype

An engagement scoped to this archetype targets:

• Migration substantially complete within the agreed six-to-nine-month window, with workload disposition matching the pre-agreed plan.
• SOC 2 controls maintained throughout the migration. Zero audit findings attributable to migration-related changes.
• Documented environment suitable for buyer technical diligence. Landing zone as code, runbooks as code, operational procedures aligned with cloud-native expectations.
• Operational capability transferred to client team by end of engagement. Post-cutover support window used for coaching and runbook refinement, not active incident response.
• Monthly infrastructure cost trending toward the modeled target (typically lower than colocation run-rate within the first two to three months, with further optimization available in follow-on FinOps engagement).

Specific percentages and dollar figures depend on the starting environment. We model these during readiness and report against them during execution.

Key decision points in this archetype

Where to run readiness and execution sequentially versus in parallel. Sequential is cleaner. Parallel is faster and riskier. Timeline pressure drives the call; the client’s operational maturity drives whether parallelism is feasible.

Which workloads to defer. A migration that tries to move everything usually slips. A migration that explicitly defers legacy workloads pending deprecation can hit the acquisition deadline. The discipline is deciding which workloads earn the refactor investment and which do not, and communicating the deferral clearly to the buyer’s diligence team.

How to handle hidden critical paths. The workload that looks straightforward at readiness and turns out to have undocumented dependencies. Every engagement of this shape has at least one. The question is whether you have built schedule buffer into the plan and whether the team surfaces the issue early enough to adjust sequencing.

Coordination with the auditor. Organizations on continuous-evidence SOC 2 need migration-era changes logged and attestable in real time. Building that into the engagement plan from week one prevents a scramble at audit time. Teams that discover this mid-engagement end up spending double the time on evidence reconstruction.

Managing the political overlay of the acquisition. Internal team members often have concerns about what the acquisition means for their jobs, which affects their engagement with the migration. The right approach is to treat the engineering team as professionals, be transparent about what is known and not known, and finish the technical work with their collaboration.

What actually decides a colocation exit

The technical migration is rarely the hard part. Four commercial and architectural questions decide whether a colocation exit is worth starting, and they are usually settled before any workload moves.

The colo contract is the clock. Colocation is bought on multi-year terms with notice periods, and the economics of a migration change completely depending on where you sit in that cycle. Leaving eighteen months of committed rack and power on the table can wipe out the first year of cloud savings, so the honest first question is when the contract renews and what notice it requires, not what the target architecture looks like.

Lift and shift versus re-architecture. Moving virtual machines as they are gets you out of the data center fastest and delivers the least benefit: the same workload on rented hardware, usually at a higher run rate. Re-architecting toward managed services captures the actual savings and takes considerably longer. Most engagements land on a split, lifting what is stable and re-architecting what is expensive to run, and being explicit about which workloads are in which category is what keeps the budget honest.

Egress is the cost nobody models. Data transfer out of the cloud is billed, and a SaaS platform serving large payloads to customers can find egress becomes a meaningful line item that did not exist under a flat colocation bandwidth commit. It should be estimated from real traffic before the business case is signed, not discovered in the third invoice.

Hybrid is a phase, not a destination. Almost every migration runs both environments for a period, and that period is where budgets slip: two sets of infrastructure, two sets of monitoring, and a network link between them. Planning the overlap as a defined phase with an end date, rather than treating it as an outcome, is the difference between a migration and a permanent hybrid estate nobody chose.

When this archetype does not fit

• The acquisition has closed and the buyer is driving the migration timeline. Different stakeholder dynamics, different scoping.
• The SaaS is pre-acquisition but has no specific deadline forcing function. A more deliberate sequential engagement usually serves better.
• The workload count is very small (under twenty). Smaller engagements benefit from simpler scoping.
• The starting point is already in cloud (e.g., needing to migrate between clouds). Different archetype, different approach.

If this engagement archetype matches your situation, book a discovery call. For the broader scope of cloud work this practice runs, see the cloud practice page.

Related reading: What it actually costs to leave colocation for AWS walks the cost model behind this archetype line by line. Do you need a cloud migration consultant? covers when an outside team is worth it. Cloud migration readiness assessment is the checklist we run before scoping.