Entigo
ENET

Open framework for digital sovereignty

Exit time

If your cloud provider became unavailable tomorrow, how long until your services run elsewhere?

An open framework for measuring that time, and for assessing your own readiness and your partners’, in planning, procurement and audits.

1 · Crisis readiness ladder

Which crises must a service survive?

2 · What exit time is made of

Which parts take the time?

3 · Exit time objective

Scope, speed, evidence and capacity

Contents

Why it matters

Digital sovereignty is the ability to make deliberate choices and to change them when needed.

Exit time makes that ability measurable.

“Digital sovereignty is the agency to make deliberate choices about your digital future, and the capacity to follow through on them.”

James Stewart, Lauren Kahn. Digital Sovereignty: The Power to Decide. London Publishing Partnership, 2026

Part 1

Crisis readiness ladder

Every service’s crisis readiness starts with one question: how large a crisis must it survive? The ladder divides crises into five levels.

Digital sovereignty

vendor-independent layer

5

Jurisdiction and supply chain

All providers in one jurisdiction or supply chain disappear at once.

Destination in another jurisdiction

4

Vendor

A vendor disappears everywhere: price rise, shutdown, sanctions.

Second vendor, ready to move to

IT continuity

provided by the cloud vendor

3

Geographic region

An entire region is lost, with all its data centers.

Second region with replicated data

2

Data center

A single data center is lost: fire, power outage.

Second data center in the region

1

Component

A server, disk or network link fails.

Redundant component in the same data center

The bottom three rungs are classic business continuity: cloud vendors cover them as part of their service by offering multiple data centers and regions. The fourth and fifth rungs are digital sovereignty. No vendor can protect you from losing that vendor, so at these rungs the service must be ready to move to another vendor, or to another jurisdiction, within an agreed time.

Not every service needs to meet top-rung objectives. Objectives are set service by service: business-critical services on a higher rung, the rest lower down.

Part 2

Exit time and recovery time

Exit time is the time it takes to move a service to another cloud or infrastructure provider, or to another jurisdiction: from the decision to move until the service works for its users again. Both measure how quickly a service works again after a crisis, and both can be verified through an exercise. They differ in where the service ends up.

Question
How fast is the service working again in the same place?
When it applies
The original location can be restored
Ladder levels
1–3
What it consists of
Data restore
Who usually provides it
The cloud vendor, through data centers and regions
How to verify it
An exercise, e.g. restoring from backup
Question
How fast is the service working in a new destination?
When it applies
The original location can’t be restored
Ladder levels
4–5
Who usually provides it
You, by preparing a second destination
How to verify it
An exercise, e.g. moving part of the service to another vendor

What exit time is made of

PPlatform

Outcome:
the technical capability to run the service in a new location. Includes contracts, infrastructure and toolchain.
Time from:
the decision to deployment readiness
How to shorten it:
Infrastructure as code, framework agreements with alternative providers, a self-sustained platform and toolchain (CI/CD, registries, identity) already deployed across vendors

QQualification

Outcome:
evidence that the service works in the new location. Includes adaptations, data pre-copying, testing and approvals.
Time from:
deployment readiness to a verified service
How to shorten it:
Ready-made test suites, compliance evidence as code, pre-approved destinations, neutral contract terms, regular exit exercises

DData migration

Outcome:
users are working in the new location. Includes final data synchronization and switching over usage.
Time from:
data volume, transfer speed, recovery point
How to shorten it:
Continuous replication outside the impact zone, sufficient bandwidth, data pre-copying

Invest in the slowest part first

Exit time has three parts. Shorten the slowest one, then the next. Once platform and qualification are prepared, moving a service takes about as long as restoring it.

Data restore

Moving to a new provider takes much longer than restoring from backup, because the platform and qualification have to be done first.

Part 3

Exit time objective

An exit time objective sets four requirements for a single service.

2 · Speed

How quickly must it run in the new destination?

Answer as: Hours, days or weeks

4 · Capacity

How much of the service must work there?

Answer as: Full, limited or reduced quality

Example

The e-services portal must survive losing its vendor (level 4), run in a new destination within 72 hours, with that time tested in an exercise, at full capacity.

In short: Level 4 · 72 hours · Tested · Full capacity

Requirement 3 in detail

Exit time evidence level

The exit time evidence level shows how far an exit time figure can be trusted: whether it’s based on an estimate, an exercise or real experience.

Declared

The figure is an estimate: it comes from an architecture diagram, a plan or a vendor’s promise, but nobody has verified anything.

Example: An exit plan in a document, a vendor’s answer in a tender

Tested

The exit has been carried out as an exercise and the time measured, but under controlled conditions.

Example: An exercise in a test environment, part of the service in another region

Proven

The real service has actually been moved to another location at full scale and made functional for users.

Example: An actual vendor switch, an unannounced exercise in production

Evidence expires. After any major change, the level drops back to declared until new evidence is produced.

The overall exit time evidence level equals that of the weakest service.

Measuring exit time

A number without an agreed method is worse than no number at all: it gives the impression that the risk has been assessed. Before you measure speed for any service, agree on:

  • What is the service, and what does it include?
  • Which dependencies do you take into account?
  • Which activities count towards exit time?

Example:

ServiceDependenciesScopeSpeedEvidenceCapacity
E-services portalcloud, identity, CI/CD4 — vendor72 hourstestedlimited
Registry databasedatabase, key management3 — region4 hoursprovenfull
Document managementSaaS, identity4 — vendor3 weeksdeclaredlimited
Notification servicenot mapped—unknown——

Balancing risks

The more differentiating a component is, the fewer alternatives exist on the market. Competitive advantage means having what others don’t. But the fewer the alternatives, the longer P and Q become, because there’s no ready destination.

Alternatives on the marketManyOneHow differentiating the component isEveryone has itOnly you have itCompetitiveness riskSustainability riskVirtual machinesKubernetes, PostgreSQLManaged data platformLeading AI modelsYour own unique feature

Tap a point for details.

Competitiveness risk

If we only use what everyone else has, we arrive later, at higher cost and with less capability. This risk materializes every day, in small amounts.

Exit time is short: there are many destinations and they’re standard.

Sustainability risk

The service depends on a single vendor, jurisdiction or supply chain. If that disappears, there is no replacement. This risk materializes suddenly and all at once.

Exit time is long or unknown: a destination has to be found or built when needed.

Choose the risk for each service separately

For each service, ask: does it need to never stop, or does it need to stand out?

It must never stop

Business-critical system

Built from
Standard components with many alternatives
Risk you accept
Competitiveness risk: you use what others use
On the chart
Left side
If the provider disappears
Move to an equivalent provider and keep running as normal.
Cost of being ready
Low: standard alternatives already exist.
Example objective
Level 472 hoursTestedFull capacity

It must stand out

Differentiating service

Built from
Components with no substitute yet
Risk you accept
Sustainability risk: you depend on a few providers
On the chart
Right side
If the provider disappears
Switch to a backup, such as a simpler AI model or manual work, and keep running in a limited mode.
Cost of being ready
Higher: there is no full replacement yet, so a limited mode is the accepted trade-off.
Example objective
Level 41 dayTestedLimited mode

Same scope and evidence. The difference is how fast the service moves and how much of it keeps working. Most organisations have both. Set the objective service by service.

First steps

towards measuring exit time

  1. Choose and define

    Select the services whose critical functions must always work. Agree on their boundaries, dependencies and what counts towards exit time.

  2. Measure today

    Write down each service’s current exit time (hours, weeks or months) and its evidence level.

  3. Set objectives

    For each service, set scope, speed, evidence and capacity.

  4. Improve and prove

    Invest in the part that takes longest (P, Q or D), then run an exit exercise to raise evidence from declared to tested.

Further reading

Glossary

TermIn EstonianDefinitionExample
Digital sovereigntyDigisuveräänsusThe ability to make deliberate choices about your digital future and to carry them out.A critical service can be moved to another jurisdiction if needed.
MovabilityLiigutatavusThe ability to change choices already made: switch location, vendor or jurisdiction. The goal is not independence but freedom of choice.A service moves to another cloud without redevelopment.
Exit timeVäljumisaegThe time it takes to move a service to a new destination, from the decision to a working service.A SaaS service moved to another cloud vendor in one month.
Recovery timeTaasteaegThe time it takes to restore a service in the same location. A special case of exit time where P and Q are zero.A service is restored from backup in the same region in under an hour.
Exit time objectiveVäljumisaja eesmärkScope + speed + evidence + capacity for a single service.Level 4, 72 hours, tested, limited capacity.
Exit time evidence levelVäljumisaja tõendustaseHow far an exit time figure can be trusted: declared, tested or proven.Tested: the exit has been carried out in a test environment.