Cloud Exit Consulting
Cloud was supposed to reduce costs. If it hasn’t – that’s a solvable problem.
Cloud exit – repatriating workloads back to on-premise, switching cloud providers, or restructuring your cloud estate to cut waste – is one of the most technically and commercially complex infrastructure decisions an organisation can make. Most cloud consultants specialise in getting you into the cloud. Very few have deep experience helping you exit it, reduce it, or restructure it when the original case no longer holds. This is where I focus.
I work with organisations of all sizes – from fast-growing SMBs whose cloud bills have unexpectedly ballooned, to large enterprises managing complex multi-cloud estates that need strategic restructuring. Whether you need a clear-eyed assessment of whether exit makes sense, or someone to lead the full repatriation end-to-end, the engagement can be sized to match your actual situation.
Specialist service
Most cloud architects focus on cloud adoption. Cloud exit requires a different mindset, different economics, and different technical patterns — few practitioners have done it at depth
Cloud-agnostic expertise
AWS, Azure, GCP, OCI, Oracle Cloud, Orange Cloud, and others – most cloud platforms share the same underlying principles. My experience spans multiple providers, not just one or two
Enterprise and SMB
From a quick strategic assessment for a growing business with runaway cloud costs, to leading a full enterprise repatriation programme – the engagement format matches your scale and budget
Why cloud exit expertise is rare, and why it matters
The entire cloud consulting industry was built to move workloads into the cloud. The tools, the certifications, the playbooks, and the incentives all point in one direction. An architect who can objectively assess whether your workloads should stay in the cloud, exit it, or be restructured, and then lead that process safely – is a genuinely different profile. I have led repatriation projects alongside standard cloud migrations throughout my career, which gives me an unusual perspective: I understand both directions, and I have no financial incentive to recommend one over the other.
Why Companies Exit or Restructure Their Cloud
Cloud exit is not a failure. It is a strategic recalibration, and the right answer for more organisations than cloud vendors would have you believe. These are the situations I see most often.
💸 Cloud costs that have grown far beyond the original business case
You migrated to cloud with a clear cost model. Two years later, the bill is three times what you projected and nobody can fully explain why. Data egress fees, reserved instance waste, over-provisioned services, and accumulated technical debt in cloud configuration collectively produce costs that weren’t in the original business case. This affects businesses of every size – from a 20-person SaaS company whose AWS bill has doubled, to a 5,000-person enterprise whose cloud estate has grown without governance.
🔒 Vendor lock-in that limits your options
You adopted a cloud provider’s proprietary services – managed databases, serverless functions, message queues, AI platforms – and now switching providers or moving workloads feels impossible. Vendor lock-in is often invisible until a pricing negotiation fails, a contractual renewal approaches, or a technical limitation prevents you from doing something you need to do. The question is whether the lock-in is acceptable or whether it has become a strategic risk.
📋 Regulatory or data sovereignty requirements
New regulations — GDPR enforcement, DORA, NIS2, sector-specific data residency rules, or national cloud sovereignty frameworks – are changing where data can legally reside and who can access it. Workloads that were compliant two years ago may no longer be. Some organisations find that cloud exit – or moving to a different provider with the right certifications and data centres – is the cleanest path to compliance.
🏭 Workloads that are simply cheaper on-premise
Cloud is not always the cheaper option at scale. For stable, predictable workloads – particularly those with high compute and storage demands and low variability – the TCO crossover point where on-premise hardware pays for itself typically arrives within 3–5 years. Workloads that have been running in cloud for several years at consistent utilisation are strong candidates for repatriation cost modelling.
⚡ Performance or latency requirements cloud can’t meet
Some workloads – real-time trading systems, industrial control systems, high-frequency data processing – have latency requirements that cloud cannot consistently meet regardless of instance type or network configuration. If the cloud architecture has been tuned and the performance targets still aren’t achievable, the architecture is the answer – not more tuning.
🔄 Provider switch – from one cloud to another
Sometimes exit means exiting one cloud provider, not cloud altogether. Moving from Azure to AWS, from AWS to OCI, or from a proprietary telecom cloud to a hyperscaler – each has its own migration complexity, data egress cost profile, and service equivalence challenges. I have migrated from Orange Cloud (a proprietary French telecom provider) to AWS with no prior community tooling or documentation available for the source platform. Cloud-to-cloud migrations are frequently underestimated.
What I Do
Cloud exit is not one decision – it is a sequence of decisions, each with its own technical and commercial implications. These are the components of a complete engagement.
1
Exit assessment – should you exit, restructure, or stay?
The first question is not how to exit – it is whether to exit. A proper cloud exit assessment maps your current workloads, their cloud cost profile, their on-premise cost profile, their technical dependencies, and the one-time cost of repatriation against the ongoing savings. The result is a clear financial model with a realistic TCO comparison and a recommendation that is based on your numbers, not on a provider’s assumptions. This assessment is valuable independently of what you decide to do, and it is the starting point for any exit engagement, regardless of the scale of your organisation.
2
Financial modelling – real TCO, not vendor estimates
Cloud provider TCO calculators are built to make cloud look favourable. A genuine cloud exit financial model accounts for current cloud spend (including hidden costs — egress, support tiers, reserved instance utilisation, unused services), repatriation one-time costs (hardware, migration effort, staff time), ongoing on-premise costs (power, cooling, hardware refresh cycles, staff), and the break-even horizon. For a provider switch, the model also covers data egress costs between providers, which are frequently the single largest cost in a cloud-to-cloud migration and are almost always underestimated.
3
Exit architecture and target design
If exit is the right decision, the target architecture defines what the post-exit environment looks like – whether on-premise, colocation, a different cloud provider, or a hybrid split. For repatriation, this covers the infrastructure design, network topology, storage architecture, and the approach to cloud-native dependencies that cannot be moved directly (proprietary managed services, serverless components, provider-specific APIs). For a provider switch, it covers service equivalence mapping, the proprietary service replacement strategy, and the landing zone on the new provider.
4
Exit planning – sequencing, dependencies, and risk management
Cloud exit planning is more complex than cloud migration planning in one specific way: you are running live production workloads in the cloud while moving them to their new home. The sequence matters enormously – interdependent services must move together or maintain compatibility during the transition, and the rollback plan must be more credible than “we can put it back in the cloud.” I build exit plans with realistic wave sequencing, explicit dependency maps, cutover windows that minimise operational risk, and tested rollback procedures.
5
Vendor lock-in reduction – even before full exit
Not every cloud exit situation requires leaving the cloud entirely. Sometimes the right answer is reducing dependency on proprietary services – replacing a managed database with a portable open-source equivalent, abstracting cloud-native APIs behind a compatibility layer, or restructuring storage to eliminate egress costs. These changes reduce lock-in, improve negotiating leverage with the cloud provider, and create the option to exit fully at a later point. This intermediate approach is often the best starting point for organisations that are not yet ready to commit to full repatriation.
6
Delivery leadership – from assessment to completed exit
For organisations that need more than a plan, I can lead the exit programme end-to-end – managing internal teams, external vendors, procurement, and C-level communication through the full repatriation or provider switch. This includes Architecture Board participation, vendor negotiation support, and the cross-functional coordination that determines whether an exit programme completes on schedule or stalls at the organisational level.
What Makes This Different
Cloud exit consulting is not just cloud migration in reverse. These are the specific things that matter.
No financial incentive to keep you in the cloud
Cloud consultants who are certified with a specific provider, or who earn revenue from implementation work on cloud platforms, have a structural incentive to recommend staying in the cloud. I am not paid by cloud providers and I am not trying to bill implementation hours on a cloud platform. My recommendation will be based on your actual economics and technical situation.
Experience with providers most consultants haven’t touched
I have executed exits from Oracle Cloud, Orange Cloud (a proprietary French telecom cloud), and various managed cloud environments – not just AWS and Azure. Cloud exit from a proprietary or niche cloud provider is significantly harder than exit from a hyperscaler because there is less tooling, less community knowledge, and fewer service equivalents. If your cloud situation involves a non-standard provider, I have been there.
I have led migrations and exits simultaneously
Understanding cloud migration deeply is a prerequisite for understanding cloud exit – because you need to know what dependencies were created during the migration, what cloud-native services were adopted, and what the realistic reverse path looks like. I have led cloud migrations for over a decade, which means I can assess an existing cloud environment with the same analytical discipline I would apply to a legacy data center before migration.
Right-sized for your situation – from a single call to full programme leadership
An SMB that needs clarity on whether their cloud costs justify exit can get that from a 2–3 hour structured assessment. An enterprise with a complex multi-cloud estate needs a different engagement. I work across both ends of this spectrum, and will tell you honestly what level of involvement your situation actually requires, rather than defaulting to the larger engagement.
Cloud Platforms – Exit, Repatriation, and Provider Switch
Cloud exit expertise is not certification-specific. Most cloud platforms share the same underlying principles – compute, storage, networking, identity, and data services – which means that experience across multiple providers transfers directly to exit planning and execution.
☁️ AWS
Exit from AWS – egress cost modelling, proprietary service replacement (RDS, DynamoDB, Lambda, SQS), reserved instance exit strategy, landing zone on destination platform.
☁️ Microsoft Azure
Azure service dependency mapping, exit architecture from Azure-native services, repatriation or migration to alternative platforms.
🔮 Oracle Cloud (OCI)
OCI Certified Multicloud Architect Professional (2025). Exit from OCI or restructuring multi-tenancy architecture. Rare OCI-specific depth.
🏭 Proprietary & niche clouds
Executed exit from Orange Cloud (proprietary French telecom cloud) with no prior community tooling or documentation. If your cloud provider is non-standard, I have experience where others don’t.
🔀 Multi-cloud restructuring
For organisations running workloads across multiple providers – rationalising, consolidating, or rebalancing the distribution to reduce cost and operational complexity.
Industries With Completed Migrations
🏦
Banking & Financial Services
Core banking platform migration under wartime conditions. DORA compliance benchmarking for Tier-1 Spanish bank. Emergency infrastructure protection.
🏘️
Real Estate Technology
3 European data centers to AWS for one of the world’s largest real estate tech groups. 1.5 years, zero production outages.
🏭
Manufacturing & Industrial
Independent PoC evaluation for Jabil (Fortune 500 EMS). Factory DC-to-cloud feasibility, OT/IT convergence, Azure + AWS dual-cloud assessment.
💊
Healthcare & Pharma
Legacy pharma CRM modernisation for US market entry. SOC-2, HIPAA, GxP compliance architecture. Go microservices PoC delivering 4× throughput improvement.
🚗
Mobility & Automotive
COBOL mainframe to cloud-native microservices for SIXT Leasing SE. Unified Kubernetes platform on AWS EKS. Penetration-tested security architecture.
How the Engagement Works
📞
For SMBs: quick assessment first
A structured 2–3 hour remote session to review your current cloud spend, workload profile, and business requirements. Outcome: a clear recommendation on whether exit or restructuring makes financial sense, and what the realistic next step is. No commitment beyond the session.
🏢
For enterprises: full programme
Assessment → financial modelling → exit architecture → exit plan → delivery leadership. I stay present through the full programme, adapting the plan as real constraints emerge. Can scale from advisory to Fractional CTO / Technical Lead depending on what the programme needs.
Engagement formats: Single assessment session (SMB) · Financial TCO modelling · Exit architecture & planning · Full programme delivery leadership · Independent review of an existing exit plan · Vendor lock-in reduction (without full exit) · Emergency consultation for programmes in difficulty
Common Questions
How do I know if cloud exit is the right answer for us? +
The honest answer is that you don’t know without a proper financial model — and neither does anyone else who hasn’t looked at your specific numbers. Cloud exit makes financial sense when your workloads are stable and predictable, when your cloud bill has grown significantly beyond the original business case, and when the one-time repatriation cost pays back within a reasonable horizon (typically 2–3 years). It usually does not make sense for workloads with highly variable demand, for teams without the operational capacity to manage on-premise infrastructure, or when the regulatory or geographic flexibility of cloud is genuinely needed. The assessment tells you which applies to your situation.
We’re a small business. Is cloud exit consulting relevant for us? +
Yes — and often very directly. Fast-growing SMBs frequently find their cloud bills have outpaced their revenue growth, and the team is too busy building the product to stop and review the infrastructure economics. A structured assessment of your current cloud spend and workload profile can identify significant savings opportunities — whether that means restructuring your cloud configuration, moving certain workloads out, or simply eliminating services you are paying for but not fully using. The engagement for a smaller business is proportionally smaller: a single session rather than a multi-month programme.
We want to switch cloud providers, not exit entirely. Is this the same service? +
Yes – cloud-to-cloud migration is a subset of cloud exit work. The financial modelling, service equivalence mapping, egress cost analysis, and exit architecture all apply. The specific complexity depends on how much you have adopted proprietary services on your current provider – the more proprietary the dependencies, the more architectural work is required to create a portable equivalent before the migration begins. I have executed cloud-to-cloud migrations from non-standard providers (including Orange Cloud, a proprietary French telecom platform) where there was no prior community documentation or tooling available.
Can we reduce cloud costs without a full exit? +
Absolutely – and for many organisations this is the right starting point. FinOps review, reserved instance optimisation, right-sizing, egress cost reduction, and elimination of unused services can produce significant savings without any repatriation. Vendor lock-in reduction – replacing proprietary managed services with portable equivalents – improves your negotiating position and reduces your dependency on a specific provider without requiring you to leave. I can assess your current cloud configuration and identify the fastest paths to cost reduction, and give you an honest view of where restructuring ends and full exit begins.
How long does a cloud exit take? +
Assessment and financial modelling: 1–3 weeks depending on the complexity of your environment. For a targeted exit of specific workloads (a single application or service cluster), execution can complete in 4–8 weeks. For a full enterprise cloud exit across multiple environments and teams, 6–18 months is realistic. The single biggest variable is how much technical debt exists in your cloud configuration – undocumented environments, deeply embedded proprietary service dependencies, and lack of internal knowledge all extend the timeline.
Ready to find out whether cloud exit makes sense for you?
In 30 minutes I can give you an honest initial read on your situation – whether exit is likely to make financial sense, what the key risks are, and what a structured assessment would involve. No commitment required.
This applies whether you are a small business with a growing cloud bill or a large enterprise evaluating a full repatriation programme.