Writing the Exit Plan into the Contract Before You Sign It

Your leverage peaks the day before signature

Nobody wants to discuss the breakup while planning the start. That is why most infrastructure and managed service contracts get signed with a termination clause three sentences long, two of which concern settling invoices. Two years later, when the business needs to move, it discovers it is negotiating from the weakest possible position: the systems run on the other party’s infrastructure, the documentation lives in their internal wiki, and nothing obliges them to help you leave.

The framing is simple. Before signature, you have something the provider wants and they hold nothing of yours. After signature, that reverses. So everything to do with leaving belongs in the first round of negotiation, alongside price.

One caveat runs through the whole article: this is a list of commercial and operational issues to address, not legal advice. Have counsel draft and review these terms and check them against whatever framework applies to your industry and your data.

Data return: format, scope, deadline

A data return clause is only worth something when it states three things: what is returned, in what form, and within what period. A generic sentence about the provider assisting the customer in retrieving its data does almost nothing when the relationship turns sour.

On scope, be more specific than customer data. Include business data in databases, files and stored objects, schemas and metadata, system configuration, alert definitions and monitoring dashboards, logs within their retention window, infrastructure described as code, and automation written specifically for you.

On format, require open formats readable without the provider’s proprietary tooling. Native database dumps, flat files such as CSV or JSON with a described structure, and text-based configuration. Where something exists only in a proprietary format, require documentation sufficient for a third party to reconstruct it.

On timing, set deadlines in days from request, and separate the first extract from the final one taken before service ends. Also negotiate periodic extracts throughout the term, not only at termination; a quarterly export you hold yourself is the cheapest insurance on this list. Finally, settle cost: the final return belongs inside the base obligation, while out-of-scope requests can be charged at rates agreed in advance.

Deletion certification

Getting your data back is half the job. The other half is ensuring the provider’s copies do not live on indefinitely. Ask for a deletion process that produces a written certificate naming which systems were cleared, when, by what method, and who signed it off.

Backups need explicit handling, since your data almost always sits inside backup cycles and cannot be selectively erased on demand. The workable answer is a stated retention cycle written into the contract, with backup copies remaining encrypted and unread for any other purpose in the meantime.

Do not forget where data pools outside the primary systems: test environments, attachments in support tickets, centralised log stores, and extracts engineers create during incidents. If the contract lets the provider retain data for its own record-keeping, require that carve-out to be narrow and time-bound, and have counsel review the wording.

Documentation and runbooks should be handed over continuously

Documentation clauses are usually written as an end-of-contract event. That is a mistake, because documentation written hurriedly in the final week is always poor. State instead that documentation is yours, stored in a repository you control, and maintained as routine work.

• Architecture and data-flow diagrams, updated whenever something material changes.
• Runbooks for common failure scenarios, with alert thresholds and the handling for each.
• Recovery procedures: restore from where, using which commands, how long it takes, how it is verified.
• An inventory of accounts, privileges, keys and certificates with expiry dates.
• Infrastructure code, deployment scripts, release process, rollback method and external dependencies.
• A log of significant architecture decisions and the reasoning behind them.

That last item is most often skipped and most valuable at handover: knowing why a system was configured a certain way is what stops a new team breaking constraints they cannot see.

The knowledge-transfer obligation

Documents do not replace people. Put a quantified knowledge-transfer obligation in the contract: a number of working sessions between the two engineering teams, recorded or minuted, within a defined window after notice is given. Name the roles that must attend, at minimum the engineers who actually operated the estate rather than only the account manager.

Content should cover an architecture walkthrough, performing a deployment and a restore together, reviewing the alert catalogue, and explaining the accumulated exceptions and special cases. Those exceptions, typically written down nowhere, are what makes transitions fail.

Notice periods must be symmetrical and realistic

Check both directions, because they are frequently unbalanced. A contract requiring six months notice from you while permitting thirty days from the provider places all the risk on your side.

Ask precise questions. Does notice run from the date sent or the date received? What delivery method counts as valid? Does the agreement auto-renew, and if so how wide is the window to decline renewal? That is the most common trap of all: an automatic renewal with a narrow window can lock you in for another full term because a calendar date slipped past. Set an internal reminder at least sixty days before that window, on the day you sign.

Notice must also be long enough that you can genuinely move. If migration takes four months, thirty days notice plus thirty days of assistance is an exit only on paper.

Termination for convenience versus termination for cause

These two mechanisms serve different purposes and you want both. Termination for cause lets you leave when the provider fails to deliver. It sounds powerful but is often hard to use, because you must evidence the breach, allow a cure period, and while the argument runs your systems are still sitting there.

Termination for convenience lets you leave without proving fault, usually against a fee or a longer notice period. It is far less contentious and in practice is the clause you are most likely to use. If the provider wants an early termination charge, pin down how it is calculated, what it is capped at, and whether it tapers as the term progresses.

Attach measurable thresholds to the for-cause right, for example missing the top-severity commitment in several consecutive months. Measurable triggers make the clause usable rather than decorative. Drafting them is work for your counsel.

Transition assistance and who pays for it

This is the most commonly missing clause and the most expensive absence. Define how long the provider must keep delivering the full service after notice, and to what extent they must actively support the move.

1. A minimum transition assistance period, plus your right to extend it once or twice at rates fixed in advance.
2. Confirmation that the SLA remains fully in force throughout the transition, with no quiet downgrade.
3. Engineering days included, and the rate for anything beyond, written into the contract rather than quoted later.
4. An obligation to cooperate directly with the incoming provider, including joint technical sessions and support during any parallel run.
5. A statement that assistance obligations apply on every termination ground, including one where the provider believes you are at fault.

That last point matters more than it looks: if assistance is suspended whenever there is a dispute, any disagreement becomes leverage to keep you where you are.

Account, licence and domain ownership

Check whose name is on each thing. Cloud accounts should be owned by your company, with billing and root privileges held by you and operating access granted to the provider. The reverse pattern, where accounts sit under the provider’s own agreement, turns leaving into a technical migration rather than an administrative change.

Domains and certificates should be registered to your company with direct access to the registrar account. DNS records should live somewhere you control. Software licences bought in your name must be transferable, and licences that belong to the provider should be listed so you know what you will have to repurchase. Public IP ranges, private interconnects and third-party agreements also belong on the inventory with a note on transferability.

For software developed specifically for you, clarify intellectual property in source code, documentation and automation, plus the licence scope for shared components the provider brings with them. This is drafting work for counsel.

Non-payment and vendor failure

These two scenarios receive the least thought and carry the heaviest consequences. First, the suspension clause for late payment. Read it carefully: after how many days is service suspended, is prior notice required, and critically, is your ability to retrieve your data cut off at the same time? A balanced clause separates stopping the service from holding the data, and allows a cure period after written notice.

Second, the case where the provider ceases trading, is acquired, or can no longer deliver. Discuss suitable mitigations with counsel, such as a change-of-control termination right, escrow of source code and documentation with a third party, or terms governing assignment of the agreement. In parallel, use the technical controls you own outright: keep a copy of your data outside the provider’s estate, keep documentation in your own repository, and make sure you hold root on the accounts that matter. Technical controls have the advantage of not requiring a court.

Rehearse the exit

An untested clause is an assumption. Once a year, request a data extract in exactly the format the contract specifies and check whether you can restore from it, ask an engineer unfamiliar with the system whether the documentation is followable, audit the account and licence inventory, and re-check the auto-renewal dates. The exercise usually surfaces a gap while fixing it is still cheap.

How HiTechCloud can help

HiTechCloud operates infrastructure for customers on AWS, Google Cloud and in-country infrastructure, as an AWS partner and a Google Premier Partner. We can work through the operational substance behind the clauses in this article with your team, including data return formats and process, keeping documentation and runbooks in a repository you control, cloud account ownership models, and the handover plan for the end of an engagement. The drafting and legal review should be done by your own counsel.