Portability, reversibility, and exit

Define what must be portable

“Avoid lock-in” is too broad to design or test. Decide which assets and capabilities must move, how quickly, under what failure or commercial condition, and with what acceptable loss.

Portability may be required for:

• Source, containers, packages, automation, and configuration.
• Model weights, adapters, prompts, evaluation suites, and serving contracts.
• Documents, metadata, embeddings, indexes, permissions, and lineage.
• Identities, roles, policy rules, keys, secrets, and audit mappings.
• Logs, metrics, traces, evidence, decisions, and retention records.
• Runbooks, skills, support processes, capacity models, and recovery procedures.

Separate portability from reversibility

Portability is the ability to move or recreate an asset or workload in another supported environment. Reversibility is the practical ability to change a decision without unacceptable cost, delay, loss, or control failure.

A standard API may improve code portability while data semantics, policy, evaluation, operations, and evidence remain provider-specific.

Define exit scenarios

Plan for several triggers:

• Commercial or strategic provider change.
• Service, model, region, version, or support retirement.
• Security incident or unacceptable dependency change.
• Legal, contractual, policy, or data-boundary change.
• Capacity, performance, reliability, or cost failure.
• Need to operate during prolonged external disconnection.

Each scenario may require a different time objective and target environment.

Portability record

Asset or capability:
Current authoritative format and owner:
External dependency:
Required target or alternative:
Maximum transition time and acceptable loss:
Export, transformation, and validation method:
Security and evidence requirements during transfer:
Last successful test:
Known gaps and owner:

Design techniques

Use explicit internal contracts, immutable artifact identities, exportable formats, infrastructure automation, separated adapters, reproducible evaluation, independent evidence, documented operational processes, and retained skills. Do not add abstraction without a real portability requirement; unnecessary layers can increase complexity and reduce reliability.

Test the exit

Paper plans are insufficient for material dependencies. Run representative export, restore, endpoint substitution, model replacement, policy migration, evidence retrieval, and recovery exercises. Measure time, data loss, behavior differences, manual steps, skill gaps, and control degradation.

Record trade-offs and accepted limitations in an architecture decision record.