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.

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.