Moving to the cloud starts with an exit plan

Context

We document how you can leave your cloud provider on the day you join. The exit plan belongs in the initial decision: which data you can take with you, in what format, with which dependencies and at what cost.

Somewhere on your premises is a server running almost everything: the ERP, the document archive, shared folders, perhaps an application built for your business years ago. It has served you well. Now the support contract is ending and renewal looks uncertain. Someone suggests the cloud, but nobody has a clear answer when you ask what happens if you want to move again.

That is where we start: keeping the business running and preserving your ability to choose.

This representative scenario draws on our experience in services and manufacturing. It brings together recurring problems and decisions without presenting them as one client's story.

The challenge

1. Nobody has agreed how much downtime the business can tolerate. “We can't stop” states a priority but leaves the practical decisions open. Which activities must continue? Which can wait, and for how long? We agree those limits with the people responsible for the business, involving IT in assessing the options. The answers determine redundancy, backup frequency and recovery arrangements. Until continuity has been defined, its cost cannot be assessed properly.

2. Data must remain consistent throughout the move. The Manuale di abilitazione al cloud, published on docs.italia.it (v1.4, 13/09/2026), identifies migration risks including data loss or inconsistency, corruption, prolonged outages and interference when source and destination environments are used simultaneously. These risks need preventive measures and checks. If both environments accept changes, we need to know where each update goes and which copy is authoritative.

3. There are practical reasons to worry about lock-in. The same manual (v1.2, 07/06/2026) links lock-in to high exit costs and insufficient information for another provider to take over. Exporting the data is only part of the job. A replacement provider also needs configurations, access, operating procedures and an understanding of dependencies. Without that information, they have to reconstruct how the service works before they can run it.

4. Someone must take responsibility for spending. An on-site server has recurring costs too: support, electricity and maintenance. In the cloud, part of the bill varies with usage. Forgotten test environments, unnecessary stored copies and outbound transfers can all add costs. We establish who reviews consumption, who can provision resources and when a change in spending needs attention.

The numbers to watch

These questions define what the project needs to measure. The first two require business decisions; the rest help establish whether the service meets those requirements.

• How much downtime can you tolerate, and when? Two hours overnight and two hours during dispatch have different consequences. Which window is acceptable?
• How much recent work could you afford to lose? Ten minutes of orders, an hour or a day are possibilities to assess, not default settings.
• How long do routine tasks take today? If you repeat an operation a hundred times a day, how much time goes on waiting?
• How does monthly spending compare with the estimate? What variance should trigger a review, and who handles it?
• How much data leaves the provider each month, and what does that cost? Does the calculation include exports and copies sent to other environments?
• How long does full recovery take? In a dated test, how long elapsed between starting the procedure and having a usable application?
• How much time and money would changing provider take? Does the estimate cover transfers, rebuilding services and testing the replacement environment?

The approach

1. Agree what the business can tolerate. We start with activities: taking an order, retrieving a document, preparing a dispatch. For each, we identify the applications and dependencies involved, then agree acceptable downtime and data loss. We record those limits and who approves them. IT assesses how to meet them; the people responsible for the business decide whether the cost is justified. When requirements change, we review the choices together.

2. Test recovery before moving services. We restore a backup into a separate environment and check that the application is usable. That means checking data, attachments, permissions, configurations and the connections needed for everyday work. A missing certificate or a folder excluded from the backup can prevent recovery even when the main database is intact. We record the time taken, problems found and fixes required. The test must establish that the service can actually run.

3. Move in planned waves. We group services according to their dependencies and business impact, starting where the consequences of a problem can be contained. Each wave has an agreed window, functional checks, criteria for proceeding or stopping, and a rollback plan with stated timings. Where environments overlap, we specify which accepts changes and how those changes reach the other. Rollback must also account for data written since the switch: restarting the old server may leave recent work behind.

4. Plan the exit at the outset. We prepare the exit plan when the project begins. It records export formats, access requirements, dependencies on managed services and components that would need replacing or rewriting. We estimate time and cost, making the assumptions explicit. We check whether exported data can be used elsewhere and record anything still untested. The plan is updated as the system changes; instructions for an obsolete architecture offer little practical help.

What changes

In this scenario, progress means being able to answer operational questions using current documentation and test evidence. Managed services also need clear responsibilities: who checks backups and updates, who receives alerts and who responds, within agreed times.

• When could we resume work after a failure? The answer rests on a recovery test and the conditions under which it ran.
• Why are we spending more this month? The difference can be traced to usage and individual charges.
• How do we test a change? The test environment has separate access, an owner and a shutdown date.
• How would we change provider? The exit plan distinguishes verified steps, dependencies and work still to be tested.
• Where is our data, and who can access it? The contract, documentation and configuration must tell a consistent story.

What people fear, and what we answer

“Once we're in, we won't be able to leave.” Some managed services make moving harder, particularly when applications depend on their specific features. An exit plan makes that cost visible; removing it entirely may be impossible. We assess which dependencies are worth accepting. Keeping the option to move can mean more documentation, regular testing and components that require more effort to manage. Those costs belong in the decision alongside the benefits of the service, before you commit.

“The monthly bill will be a surprise.” An estimate relies on assumptions about usage. We check them during migration and once the service is in everyday use. Running old and new environments together can also add costs. We assign owners to resources, set alert thresholds and review the bill each month. That oversight takes time too. An alert flags a variance; someone still has to identify the cause and decide what to do about it.

“We'll lose control of our data.” An infrastructure provider adds another party to the handling of your data. We keep our own work within the European Union; the project establishes where data will be held and who may access it. We check those decisions against the relevant agreements and actual configuration. Location alone does not settle access control. Permissions must be verifiable, access must be revoked when appropriate, and checks must continue. That requires clear ownership and time after migration as well.

How we approach it today

Moving a system that supports everyday work requires an understanding of its dependencies, agreed limits on disruption and tested recovery. The exit plan is part of the opening discussion and remains part of running the service. These pages explain how we work with business applications and ERP systems:

• Custom software development
• Our Odoo Partner path

Have an on-site server with support about to expire? Let's talk. We'll start with what needs to keep running and what it would take to preserve your choice of provider. 30 minutes, with no obligation.