Today I needed to find out whether a system was really mine.

Not in the legal sense. The account was under control, access existed, and nobody had kidnapped the server in a dark parking lot.

The question was simpler and much more uncomfortable:

if I had to remove that operation from its current environment and rebuild it somewhere else, what could I actually take with me?

During an infrastructure outage, a recent backup of a few automation workflows allowed me to understand how a service behaved and plan its migration to a simpler architecture. The copy did not solve the whole incident, nor did it get up and walk into the new environment on its own. It did something perhaps more important: it restored my ability to decide.

I could preserve what made sense, discard the excess, and choose another path with enough evidence not to depend solely on the memory of whoever had assembled everything.

That was when the backup stopped looking like nothing more than disaster insurance.

It became evidence of autonomy.

TL;DR

Administrative access, paying the bill, or owning part of the code does not guarantee operational sovereignty. A system remains governable when its data, workflows, configuration, dependencies, secrets, and validation criteria can be recovered, understood, and rebuilt in another environment. Backup is raw material for that capability, but a copy without testing, a usable format, documentation, and a possible destination may be just a very well-kept file. This is not an anti-cloud or anti-managed-services manifesto. Those services can reduce cost, work, and risk. The point is to use convenience without outsourcing the ability to leave, migrate, or simplify as well.

Having access is not the same as being able to take it with you

It is easy to confuse access with operational ownership.

I can sign in to the dashboard. I can change settings. I can see charts. I pay the bill. There may even be a button labeled Export.

Great.

Now try answering these questions:

• can the exported file be restored without the original platform?
• do the workflows remain understandable outside that interface?
• are important settings recorded, or do they live in clicks accumulated over several years?
• are dependencies and versions identified?
• can secrets be rotated and reprovisioned without copying credentials in plain text?
• is there a verifiable way to know whether the rebuilt system does the same job?

If none of these questions has an answer, I may have access to the system without having real control over its continuity.

An Export button that produces an undocumented proprietary file is not exactly independence. It is a compressed request for help.

The backup gave a decision back to me

In the situation that led to this article, I did not need to reproduce the entire previous architecture blindly.

In fact, part of the work was figuring out what did not need to survive.

The workflow backup made it possible to identify:

• which behavior had to be preserved;
• which integrations were actually necessary;
• which pieces had been created for temporary convenience;
• where complexity existed without proportional benefit;
• what the smallest architecture capable of preserving the outcome would be.

That distinction matters.

Restoring means trying to return something to a known state. Migrating means carrying capabilities into a different context. Rebuilding may mean preserving the intent while changing the implementation considerably.

Sometimes I want to return to exactly where I was.

Sometimes, after opening the box, I realize that going back would merely be a technically flawless way to repeat the problem.

That is why a recoverable backup does more than bring the old system back online. It also allows us to investigate, compare, simplify, and decide whether that design still deserves to exist.

Data is only one of the layers

When someone says, “we have backups,” my next question is: backups of what?

A real system usually depends on several layers:

Layer	What needs to survive	What commonly goes wrong
Data	Databases, files, events, and persistent state	The copy exists but is incomplete, corrupt, or trapped in the source format
Behavior	Workflows, rules, code, automations, and policies	The data returns, but nobody can reproduce what the system did with it
Configuration	Variables, topology, versions, and parameters	The operation depended on manual clicks that were never recorded
Dependencies	Services, images, libraries, interfaces that let systems communicate (APIs), and external contracts	The recovery calls a version that no longer exists or an integration that changed
Secrets and identity	A safe way to recreate access, keys, and technical accounts	A secret was copied insecurely or there is no rotation procedure
Verification criteria	Tests, health signals, samples, and expected results	The system starts, but nobody can prove it returned correctly
Operational knowledge	Recovery order, limits, owners, and a safe return to the previous state (rollback)	Everything works while the person who built it is available and remembers the details

Saving only the database may protect the content while leaving the operation unrecoverable.

Saving only the code may produce a perfectly empty application.

Saving the configuration with exposed secrets may turn continuity into a security incident.

Backup is not a folder. It is a capability spanning different layers.

A copy does not prove recovery

The NIST Cybersecurity Framework 2.0 includes, under PR.DS-11, the outcome that data backups are created, protected, maintained, and tested. Its implementation examples mention testing backups and restores for different data sources and keeping some copies separate from the primary environment.

The CISA guidance on ransomware follows a similar direction: maintain critical backups offline and encrypted, test their availability and integrity, and preserve reconstruction assets such as golden images, source code, and declared infrastructure files.

These sources support one objective part of the argument: creating the copy does not finish the job.

They do not prove that every company should change providers, use the same architecture, or host everything itself. Nor do they prove that one annual test is enough for every operation. Frequency, separation, and depth need to follow impact, rate of change, and acceptable recovery time.

A useful test does not end with “the file opened.”

It asks whether, in a clean environment, we can:

1. locate the right copy;
2. validate its integrity;
3. restore data and behavior;
4. reprovision access without exposing secrets;
5. connect known dependencies;
6. verify the expected outcome;
7. record how much time and manual intervention were required.

It is a rehearsal for autonomy, not a ceremony for turning a spreadsheet cell green.

Portability begins before the migration

In 2012, NIST SP 800-146 already described workload portability as the practical ability to move data or an entire workload back to a consumer’s own infrastructure or to another provider. The publication connects this capability to standardized interfaces and formats and recognizes that provider-specific resources create obstacles.

The document is old by the standards of cloud computing. It does not describe every modern service or prove that portability has improved or deteriorated uniformly since then.

But the distinction remains useful:

portability is not born on the day we decide to migrate. It is born in the choices made while the system is still comfortable where it is.

If the data uses understandable formats, behavior is expressed in code or exportable workflows, configuration is declared and versioned, integrations have known contracts, and tests describe the expected result, moving is still work — but it stops being archaeology.

The OpenGitOps principles help name one part of that design: desired state that is declared, versioned, and retained with history. I am not saying every operation needs GitOps, Kubernetes — a platform that automates application deployment and operation — or any particular tool. The relevant principle is simpler: important state cannot exist only inside the environment I may need to replace.

The same lesson appeared when I wrote that AI forgot precisely what I had already decided. A conversation can help run an operation, but material decisions need to change state and live in durable contracts.

Infrastructure also “forgets” — figuratively — everything that never left the head of the person who configured it.

Sovereignty does not mean hosting everything under my desk

There is a caricature of technological sovereignty in which I should abandon every managed service, buy a refrigerated room, and spend Sunday updating firmware — the low-level software embedded in hardware — because freedom requires artisanal suffering.

That is not it.

Managed services can provide availability, global distribution, specialized security, automatic updates, and operational economics that many companies could not responsibly reproduce.

Sometimes using an external service is precisely the decision that reduces risk.

I do not want to operate every component. I want to govern the dependencies I chose not to operate.

To me, operational sovereignty means retaining a proportional ability to:

• access and export what belongs to me;
• understand the format and meaning of what was exported;
• rebuild critical parts in another environment;
• replace a dependency without rewriting the entire company;
• preserve security during the transition;
• verify that the new state remains correct;
• consciously accept the areas where migration would be expensive.

Not every form of coupling is a mistake. Some buy valuable capabilities.

The problem is discovering the exit price only when the door is already on fire.

The architecture needs an exit

When I assess a new system, I do not want to ask only what it can do in the demo.

I want to know:

• what data goes in and how it comes out;
• which formats are documented and usable;
• what depends exclusively on the provider;
• how workflows and configuration are versioned;
• who holds and rotates secrets;
• which parts can be reproduced automatically;
• how drift between intended configuration and the real environment is detected;
• which tests prove behavior rather than mere availability;
• what the plan is if the service changes, shuts down, or stops making sense;
• how much knowledge is concentrated in one person, one dashboard, or one conversation.

This connects to what I wrote about generic agents being a terrible first contact with AI. A reusable foundation is valuable. A closed box that reuses conclusions, hides dependencies, and prevents the company from understanding its own operation is something else.

There is also no point in turning portability into an architectural religion. As in the article about starting with the bottleneck instead of the desire to add AI, the answer needs to be proportional to the problem.

A static website, a payroll system, and a clinical system do not need the same exit plan.

Governance does not mean applying maximum control to everything. It means knowing which failure matters and how much freedom we need to preserve before choosing convenience.

A simple autonomy test

If I wanted to assess the situation without beginning with a complete migration, I would run a bounded exercise:

1. choose an important but non-destructive capability;
2. export its related data, workflow, and configuration;
3. document dependencies and expected results;
4. prepare fresh credentials without reusing production secrets;
5. rebuild the capability in an isolated environment;
6. compare behavior, data, and recovery time;
7. record everything that still depended on memory, a manual click, or exceptional access.

The goal is not to prove that I can abandon the provider tomorrow.

It is to discover, while there is still time, what would prevent me from choosing.

The system is mine when the direction remains mine

I do not want to eliminate dependencies. I want to make them visible, deliberate, and replaceable to the right degree.

Nor do I want to rebuild every existing technology so I can claim to be in control. That would be using a bazooka to kill a fly and then hiring someone to maintain the bazooka.

I want an outage, a price change, an evolution in the business, or a better architecture not to force me to start from scratch.

The recent backup I found was not sovereignty in its entirety.

It was one piece of it.

It preserved enough behavior for me to understand the service, test another direction, and decide what deserved to continue. Its value was not only in recovering the past. It was in keeping me from becoming trapped in it.

At i-9.ai, this is one of the criteria I bring to architecture: beyond working today, an operation should keep its data, context, security, and capacity for change under the company’s governance.

If you do not know what you could recover, rebuild, or take with you from the systems supporting your operation, contact me. The conversation can start with one critical capability and one concrete question: what would need to survive if the current environment stopped being the best choice?

Further reading

• AI forgot precisely what I had already decided — why conversation, summaries, and memory do not replace a durable source of truth.
• Generic agents can be your worst first contact with AI — how to reuse engineering without hiding context, dependencies, and responsibility.
• Your company does not need to figure out where to put AI — a map for choosing process, automation, assistance, agents, or human decisions from the real problem.
• API, rollback, Kubernetes, and firmware — references for the technical terms used in the article.

References and limits of use

• NIST Cybersecurity Framework 2.0 and its implementation examples: support the statement that backups need to be created, protected, maintained, and tested. They do not define a universal frequency or prove the complete thesis about operational sovereignty.
• CISA — StopRansomware Guide: supports the recommendation to keep critical copies separate, test recovery, and preserve artifacts useful for reconstruction. Its primary context is ransomware resilience, not a general comparison between architectures or providers.
• NIST SP 800-146 — Cloud Computing Synopsis and Recommendations: provides the definitions and limitations used in the discussion of workload portability, interfaces, and formats. It was published in 2012 and does not describe the entire current cloud market.
• OpenGitOps — principles v1.0.0: supports the explanation of desired state that is declared, versioned, and retained with history. It does not imply that GitOps is mandatory or sufficient for portability, recovery, or sovereignty.