Leaving AWS or Azure is rarely a straightforward infrastructure move. An enterprise may decide to change provider because costs are rising, an acquisition has created duplicate platforms, data-residency requirements have changed, or the original operating model has not delivered the expected value.
Whatever prompts the decision, the practical question is not simply whether the organisation can leave. It is what has to change for the business to continue operating safely while it does.
Applications are connected to identity systems, CI/CD pipelines, logging, security controls, databases, DNS, third-party SaaS platforms, network routes, and teams' accumulated operational knowledge. A provider exit is therefore a business-change programme with significant engineering work, not a procurement event.
A well-run exit can reduce waste, restore strategic flexibility, and expose weaknesses that had been hidden by managed services. A poorly run one can create outages, security gaps, a long and costly dual-running period, and a replacement platform that recreates the same issues elsewhere.
Cloud exit is not the same as cloud repatriation
"Cloud exit" is often used as shorthand for moving workloads back on premises. In practice, enterprises take several different paths:
- move from AWS to Azure, or from Azure to AWS;
- move selected workloads while retaining the existing provider for others;
- repatriate particular systems to private cloud, colocation, or owned data centres;
- replace provider-specific services with more portable platforms and tooling;
- retire applications, consolidate duplicates, or replace custom systems with SaaS products.
These options have different risk profiles. Moving a conventional virtual-machine estate is difficult but familiar. Replacing an event-driven application that depends on provider-native identity, functions, queues, databases, analytics, and security services is an architectural redesign.
The target is also not necessarily another place to run the same architecture. An organisation may leave a provider while retaining the practices that worked: automated infrastructure, immutable deployments, managed databases where they make sense, and measurable service objectives. The purpose is to regain appropriate control, not to discard useful cloud practices out of frustration.
Why enterprises decide to leave
Cost has become hard to explain
A cloud bill can grow faster than the organisation's ability to attribute it. Common causes include over-provisioned compute, ungoverned non-production environments, data-transfer costs, duplicate observability and security products, abandoned storage, and commercial commitments that no longer match demand.
The instinctive response can be to leave the cloud entirely. That can be appropriate for stable, predictable, high-utilisation workloads, but it is not a universal answer. Establish whether the issue is provider pricing, architectural inefficiency, weak FinOps practices, or unclear ownership first. Moving an inefficient architecture to a different platform merely changes the invoice heading.
A credible business case compares full cost of ownership over several years. It includes target-platform engineering, licences, hosting or facilities, connectivity, support, operational staff, migration tooling, dual-running, training, and contingency. It should also make the desired business outcome explicit: lower operating cost, better resilience, regulatory alignment, faster delivery, or reduced supplier concentration.
The organisation needs more strategic flexibility
A provider can become a constraint when an enterprise cannot negotiate effectively, cannot use required regions, or lacks the skills to operate increasingly specialised services. This is common after acquisitions, when business units arrive with incompatible cloud standards and agreements.
Flexibility does not mean eliminating every provider-specific technology. It means making deliberate choices about where dependency creates value and where it creates unacceptable exposure. A managed database may justify a degree of lock-in; a customer-facing data model spread across several proprietary services may need stronger portability safeguards.
Regulation and risk appetite have changed
Data location, access controls, auditability, and supplier risk are board-level concerns in many sectors. A new market, customer contract, acquisition, or internal policy can all change the requirements.
Those needs must be translated into precise technical controls before migration starts. "Keep data in country X" is not sufficient. Teams must understand backups, logs, support access, encryption keys, disaster-recovery copies, analytics exports, third-party integrations, and administrative identity paths. An exit can miss its compliance objective if production data moves while operational data remains scattered across the original provider.
The cloud operating model has not matured
Cloud services do not automatically create a cloud operating model. Teams may have adopted AWS or Azure without clear ownership, platform standards, tagging, identity governance, incident response, or deployment discipline. The environment then becomes expensive and difficult to change.
An exit can be the catalyst for building sound foundations: a clear platform team, reusable landing-zone patterns, infrastructure as code, service ownership, cost allocation, and production-readiness criteria. Those foundations need to exist before workloads move, whether the destination is another cloud or a private environment.
Westpoint's cloud engineering services connect architecture, security, migration, DevOps, and cost control. The destination matters, but the ability to operate it well matters more.
The real scope of an exit
The visible compute estate is only part of the programme. A useful exit assessment maps six connected areas.
Applications and dependencies
Each application needs an owner, business criticality, uptime requirement, data classification, dependency map, and migration path. Dependencies commonly include internal APIs, DNS zones, certificates, message brokers, shared databases, batch jobs, SFTP endpoints, SaaS integrations, and partner networks.
Dependency discovery cannot rely solely on CMDB data. It needs evidence from application telemetry, network flows, deployment configurations, source repositories, and conversations with the people who support the service. The surprising dependency is usually the one that delays cutover: a nightly report, a hard-coded IP address, a legacy SMTP relay, or an unmanaged integration owned by another team.
Data
Data migration determines the pace and risk of many exits. Large datasets take time to copy, but the harder problem is keeping source and target systems consistent until cutover.
For every data store, decide whether the target will use native replication, logical replication, change-data capture, export and import, application-level dual writes, or a planned outage. Define reconciliation before moving anything: row counts alone are not enough for financially significant or operationally critical data.
Data also has a long tail. Object storage, archives, backups, snapshots, logs, data lakes, machine-learning artefacts, container images, secrets, and audit records may still matter after an application has moved.
Identity and access
Identity is often the hidden centre of cloud dependency. Workloads may use provider-native service identities, role assumptions, managed identities, federated SSO, privileged-access workflows, and secrets systems that are tightly coupled to the current cloud.
Design the target identity model early. It should cover workforce access, workload authentication, service accounts, break-glass access, key rotation, CI/CD credentials, and least-privilege permissions. Leaving this until final migration waves leads to insecure shortcuts and fragile deployments.
Network, DNS, and operations
Cloud exits often expose years of informal network assumptions. Address ranges may overlap, routes may have been added ad hoc, firewall rules may have weak ownership, and applications may rely on private endpoints or provider-specific service discovery.
Build the target network and connectivity model before migration. Test DNS resolution, certificate renewal, egress controls, latency-sensitive integrations, disaster-recovery routes, and third-party allowlists.
An application is not migrated because it starts successfully in a new environment. It is migrated when the right teams can deploy it, monitor it, secure it, support it, restore it, and recover it under pressure. For every migration wave, confirm monitoring, alerting, backup-and-restore testing, vulnerability management, incident runbooks, performance baselines, support access, audit trails, deployment, and rollback.
Managed services change the migration pattern
The more provider-native services an estate uses, the less useful a lift-and-shift mindset becomes.
A virtual machine running a self-managed application can often be rehosted with limited code change. A serverless application using managed event routing, functions, object-storage triggers, identity policies, and proprietary database features may need redesign. The same is true for analytics platforms, managed Kubernetes add-ons, infrastructure-policy tooling, AI services, and API gateways.
That does not mean managed services were wrong decisions. They may have reduced operational effort and accelerated delivery. It does mean the exit needs an honest classification:
- Rehost: move the workload largely unchanged.
- Replatform: retain application behaviour while replacing hosting or managed components.
- Refactor: alter code and architecture to reduce provider dependency.
- Replace: adopt SaaS or a packaged product.
- Retire: decommission the capability entirely.
AWS's migration guidance describes a comparable range of strategies, including retire, retain, rehost, relocate, repurchase, replatform, and refactor. In an exit, apply that classification to the desired target state rather than assuming every workload deserves the same treatment.
Avoid refactoring everything at once. For a broad programme, move low-risk workloads first, build repeatable patterns, and reserve deep modernisation for systems where the business case supports it. Trying to redesign every application before an exit deadline is a reliable way to lose both schedule certainty and engineering focus.
The cost traps that appear during exit
Cloud exits can save money, but the transition itself can be expensive.
First, data-transfer charges can be material. Forecast movement by workload, include retries and replication overhead, and model the duration of dual running. Do not treat egress as a minor administrative cost.
Second, target environments are frequently overbuilt. Teams create duplicate production-grade capacity before understanding actual workload shape, particularly when they are trying to reduce perceived cloud risk. Measure demand and build incrementally.
Third, licences can become more expensive after the move. Database, operating-system, observability, security, and virtualisation licensing all need target-state validation. A change in cores, hardware, tenancy, or support model can invalidate the original business case.
Finally, productivity costs are often omitted. New platforms introduce new operational routines, tooling, deployment paths, and on-call expectations. Training, documentation, pairing, and early-life support are delivery work, not optional extras.
A cloud readiness assessment turns these assumptions into a prioritised risk and delivery roadmap before major spend is committed.
A practical exit roadmap
1. Establish the decision and guardrails
Define why the enterprise is exiting, what success looks like, what remains in scope, and what cannot be compromised. Put numbers against the outcome: target savings, required compliance controls, deadline constraints, acceptable downtime, and service-level expectations.
Create an executive sponsor, an accountable programme leader, and named owners for architecture, security, data, finance, procurement, applications, and operations. A cloud exit crosses all of these functions; weak ownership creates slow decisions and uncontrolled exceptions.
2. Inventory and segment the estate
Build a portfolio view that combines business value and technical complexity. Identify quick wins, stranded costs, systems that should be retired, critical shared platforms, and applications requiring refactoring.
Do not start only with the loudest application owner or the largest monthly bill. Prioritise a pilot wave that is representative enough to test the target platform but safe enough to expose process gaps without risking core operations.
3. Build and test target foundations
Before migrating production workloads, establish the target landing zone, identity, network connectivity, security baseline, observability, backup, infrastructure-as-code patterns, and support model.
This is where cloud consultancy can shorten the gap between a strategy document and a working platform. The target must be usable by delivery teams, not just compliant on a diagram.
4. Create a migration factory
Standardise discovery, design review, data transfer, cutover, validation, rollback, and post-migration handover. Each completed wave should improve the next one.
A repeatable migration factory creates predictable delivery and makes it easier to distinguish genuine exceptions from issues caused by inconsistent execution.
5. Cut over with evidence and a reversible plan
Every cutover needs explicit go/no-go criteria, communications, a rollback threshold, validated backups, reconciliation steps, and named decision-makers.
Testing must include functional behaviour, security controls, representative performance, integrations, operational alerting, and restoration. The final decision should be based on evidence, not the pressure of a contractual date.
6. Decommission properly
The programme is not finished when production traffic moves. Decommission accounts, subscriptions, credentials, DNS records, network links, backups, replicas, images, monitoring integrations, marketplace products, and support contracts in a controlled sequence.
Retain evidence required for audit, finance, legal, and operational recovery. Confirm billing has stopped and that no unmanaged dependency still directs traffic or exports data to the former provider.
Choose the platform on your own terms
The strongest cloud strategy is rarely all AWS, all Azure, or no public cloud. It is an informed decision about where each workload belongs, what level of provider dependency is acceptable, and how the organisation will preserve its ability to change course.
An exit programme is a demanding but useful test of technical ownership. If an enterprise cannot identify its dependencies, reconstruct an application outside its current provider, validate its data, and operate the target safely, those are risks worth addressing whether or not it ultimately leaves AWS or Azure.
Start by establishing the business case, mapping the estate, and testing a small but representative migration path. The goal is not to prove that cloud was a mistake. It is to build the operational and architectural discipline that lets the enterprise choose its platform on its own terms.
