A startup's guide to cloud migration

Moving a live product to the cloud is one of the higher-stakes engineering decisions a startup will make, not because the technology is exotic, but because the timing, sequencing, and target choices compound quickly into either a competitive advantage or an expensive distraction. This guide covers the full arc: when migration is genuinely worth undertaking, how to classify and sequence the work, how to manage data and the cutover with care, and how to choose a region that serves South African customers well.

When a migration is worth it, and when it is not

Most startups reach a migration inflection point in one of a few situations. A single server or shared-host arrangement is buckling under load. A legacy on-premises setup is creating reliability problems and capital expenditure the business can no longer justify. The team is on a hosting provider that lacks the managed services needed to move product faster. Those are legitimate reasons to migrate.

What is not a good reason is migrating because it feels like the right time, or because a competitor announced a cloud-native rewrite. Migration costs real engineering time and introduces real risk. If the current setup is stable, adequately scaled, and not blocking product development, staying put until a clear trigger arrives is a completely valid choice. The cleaner the trigger, the cleaner the migration. A concrete driver such as needing auto-scaling for seasonal traffic peaks is a far more reliable anchor than a general desire to modernise.

Six ways to treat each workload

Before anything moves, every component in the stack deserves a deliberate decision about what will actually happen to it. A widely used framework describes six options, sometimes called the six Rs, and working through them prevents the common mistake of defaulting to a lift-and-shift on everything simply because it is the path of least resistance.

Rehosting means moving a workload to a cloud virtual machine with minimal changes. It is fast and low-risk, though it leaves most of the managed-service value unrealised. It is a sensible choice for stateful components that need to move quickly and can be revisited in a later wave. Replatforming goes one step further: a small number of targeted adjustments let the workload run more naturally on the new platform, for example replacing a self-managed database with a managed equivalent, without rearchitecting the application. For most startups this offers meaningful gains without a full rewrite and is often the best first pass.

Repurchasing means replacing the workload entirely with a managed or off-the-shelf service. If the team is running its own email infrastructure, swapping it for a managed sending service is not really a migration at all; it is a simplification. Any workload that is not core to the product is a candidate. At the other end of the effort scale, refactoring means redesigning a component to suit the cloud more fundamentally, for instance decomposing a monolith or restructuring data access patterns. This carries the highest effort and the highest potential reward, and it should be reserved for components that are genuinely limiting the business. It should happen after a stable foundation is in place, not before.

The remaining two options are often overlooked but are just as important. Retiring means switching a workload off entirely. Migrations routinely surface services that nobody uses any more, and decommissioning them reduces cost, attack surface, and cognitive load on the team. Retaining means leaving a workload where it is by deliberate choice. Some components have compliance, latency, or contractual reasons to remain on-premises or on their current host, and acknowledging that explicitly is better than treating it as a migration failure.

For most early-stage startups the pragmatic answer is a mixture of rehosting, replatforming, and retiring, with refactoring deferred until the team has recovered from the migration itself.

A sensible order of operations

A migration is not a single event. It is a programme with distinct phases, and respecting that sequence is what separates a smooth migration from a chaotic one. The first task is to take stock of what you run: catalogue every service, its dependencies, its data stores, and its traffic patterns, and include third-party integrations. This step sounds obvious and is routinely skipped; teams pay for that omission during cutover when a forgotten dependency resurfaces at the worst moment.

Before a single workload moves, the foundational account structure, networking, identity and access controls, logging, and cost controls should be in place. A well-designed landing zone prevents security and governance debt from accumulating as workloads arrive. Our post on landing zones and infrastructure as code covers this in detail. Once the foundation is solid, choose a real but non-critical workload, such as a batch job, an internal tool, or a staging environment, and migrate it first. The pilot exposes gaps in runbooks, tooling, and access controls before those gaps matter.

After the pilot, group remaining workloads by dependency and risk, and move them in batches. Stateless services generally move before stateful ones, and internal services generally move before customer-facing ones. Each wave produces a stable, tested baseline before the next begins. Optimisation comes last. Right-sizing instances, tuning auto-scaling, and committing to reserved or savings-plan capacity all require real production traffic patterns to inform good decisions. Our post on cloud cost optimisation for startups explores this phase in depth.

Handling data and the cutover carefully

The cutover, the moment when production traffic switches to the new environment, is where most migration risk concentrates. Good preparation makes it a routine event rather than a stressful one.

Start with a full, verified backup before any cutover attempt. Verification means performing a test restore. A backup that has never been restored is not a backup you can rely on. For databases with any volume of live writes, a replication strategy bridges the gap between the initial data copy and the cutover. All three major providers offer database migration services that can maintain a continuous replication stream while both environments remain live. Once the new environment has caught up and been verified, the actual cutover becomes a matter of redirecting traffic rather than racing against a data gap.

For web-facing workloads, traffic is most commonly redirected by updating a DNS record to point to the new environment. Lower the time-to-live value on that record well in advance, ideally 24 to 48 hours before the cutover window, so that when the change is made it propagates to resolvers around the world quickly. After traffic has stabilised on the new environment, the time-to-live can be raised again to a normal value.

The most common cause of a painful cutover is a dependency that was not in the original inventory. Before any cutover, do a sweep: review firewall rules, any hardcoded addresses pointing to the old environment, credentials scoped to the old platform, and any service that calls your endpoints directly rather than through a DNS name. Define the rollback plan before starting. If something goes wrong during the cutover window, the team needs a documented, practised procedure rather than a stressful improvisation. For DNS-based cutovers, rolling back is usually straightforward provided the time-to-live is already low and the old environment is still running.

Choosing a region for South African customers

For startups serving South African or broader southern African customers, latency and data residency are genuine constraints, not theoretical concerns. Each of the major cloud providers has at least one region on the continent.

• AWS operates a region in Cape Town, designated af-south-1. This region must be explicitly opted into; it is not active by default on new accounts.
• Azure operates South Africa North in Johannesburg as its primary South African region, and South Africa West in Cape Town, which is commonly used for replication and disaster recovery.
• Google Cloud operates africa-south1 in Johannesburg.

If the choice of hyperscaler is still open, our post on choosing a hyperscaler walks through the decision factors in detail, including managed service depth, pricing structures, and ecosystem considerations. No single provider is the right answer for every team, and the decision deserves deliberate analysis rather than inertia. All three providers also offer credit and support programmes for qualifying startups, which can materially offset migration costs. Eligibility criteria and benefit amounts change over time, so it is worth checking directly with each provider rather than relying on figures from any secondary source. Credits are time-bounded, so plan to complete the migration and bring costs into a steady state before the credit period ends.

How Lambdaserve helps

Lambdaserve is a South African software studio and cloud-engineering practice. We help teams build on and migrate to Azure, Google Cloud, and AWS, handling the landing zone design, migration sequencing, infrastructure as code, and post-migration optimisation. AWS engagements are delivered in partnership with Datagnu. If you are working through a migration decision or would like a second opinion on your approach, get in touch to discuss the specifics.

Written by the Lambdaserve team as general, informational guidance for founders and engineers. It is not legal, financial or tax advice. Third-party product names, programmes and logos belong to their respective owners and are referenced for identification only.