The Sequence Is the Architecture

Migration plans are often described by the part of the system that moves first: data, interface, backend, or one feature at a time. This sounds like a scheduling choice. It is an architecture choice.

Each sequence creates a different period in which the old and new systems coexist. During that period, requests must be routed somewhere, changes may need to be synchronized, and somebody must be able to say which result is correct. The most polished target architecture does not answer those questions. The migration architecture does.

A phased migration is safer only when every phase transfers authority cleanly. If a phase leaves two plausible sources of truth, an implicit synchronization rule, or no testable exit condition, it has not reduced risk. It has extended the time during which inconsistency can accumulate.

Phased is not a safety property

Incremental replacement can limit the impact of one change. The strangler pattern, for example, uses a routing layer to move selected requests from an old implementation to a new one over time. Both AWS and Microsoft describe the façade or proxy as the place where traffic is redirected as capabilities migrate.

That pattern is useful, but the adjective “incremental” does not make a plan safe by itself. Coexistence introduces its own failure modes:

• the old and new systems both accept changes to the same fact;
• a request reaches a different implementation depending on an undocumented condition;
• synchronization is assumed to be bidirectional but is only implemented one way;
• a migrated component still relies on an old policy or operator workaround;
• the phase continues indefinitely because “done” was never defined.

Database tooling illustrates the point. PostgreSQL’s logical replication documentation says that local writes on a subscriber can conflict with incoming changes, while schema changes are not automatically replicated in the usual logical-replication flow. Some conflicts stop replication and require manual resolution. That is not an argument against replication; it is evidence that “keep both databases in sync” is not yet a synchronization contract. (PostgreSQL: logical replication, conflicts, restrictions)

The practical unit of migration is therefore not a screen, service, or table. It is an authority transfer: a bounded change after which one system is unambiguously responsible for a defined set of decisions and state.

Data context is not data authority

“Start with the data” is good advice when it means “study the data before making promises.” It is unreliable advice when it means “move the database first in every system.”

Data can reveal structure and history. Tables, fields, constraints, distributions, timestamps, and anomalous records can show:

• which entities exist and how they are related;
• which states occur in production rather than only in documentation;
• where identifiers, nulls, duplicates, and exceptional values complicate a clean model;
• which areas have high volume or frequent change;
• which apparent rules are contradicted by stored records.

But stored data does not fully explain why a state is valid. It may not reveal a policy enforced in application code, an exception approved through an operations channel, a third-party retry rule, a staff member’s correction procedure, or the meaning of a field whose name survived several product eras. A database is evidence about the system. It is not a complete specification of the system.

This is the distinction:

• Data context is what inspection of records, schemas, queries, and flows teaches the migration team.
• Data authority is the system permitted to accept a change and determine the current value of a fact.

A team can—and often should—build data context first while leaving data authority in the legacy system. Moving authority comes later, when semantics, write paths, synchronization, verification, and recovery are explicit.

Five sequences, five different coexistence problems

1. Data-context-first

Start by profiling the existing data, mapping ownership, testing extraction, defining the target model, and rehearsing transformations. This is a discovery sequence, not necessarily a production cutover sequence.

It fits when data quality is uncertain, reporting has become contradictory, or the target design depends on understanding historical states. It is also a useful prerequisite for any path that changes storage technology.

It becomes risky when “context-first” quietly turns into “new database accepts writes first.” At that point the team must decide which store is authoritative, how writes move, how lag is measured, and what happens after a conflicting update. Without those decisions, the new database is not a foundation. It is a second version of reality.

2. Interface-first

Replace or introduce the user interface while the existing backend remains authoritative. A façade, API adapter, or compatibility layer translates between the new interaction model and the old system.

This can work well when the backend already has stable contracts and the main problem is usability, accessibility, or client technology. It can also expose missing contracts early because the new interface has to call the old system deliberately rather than relying on framework-local behavior.

Reject this path when important rules live in UI events, page workflows, client-side conditions, or direct database access that has never been expressed as a backend contract. In that situation, a new interface may look complete while omitting the behavior that made the old one correct. An adapter can translate semantics between systems, but it adds operational overhead and must be monitored; AWS’s anti-corruption layer guidance explicitly treats that layer as something whose resilience, latency, and eventual retirement need decisions.

3. Backend-first

Replace services, rules, or storage behind the existing interface. The old interface becomes a client of the new backend, directly or through an adapter.

This fits when the interface is serviceable, the backend boundary is known, and the urgent problem is reliability, scale, security, or maintainability behind that boundary. It can preserve user routines while the internal authority changes.

Reject it when the old interface is inseparable from the old execution model—for example, when it reads shared tables directly, relies on undocumented response quirks, or embeds authorization decisions locally. Backend-first also needs a precise answer for historical jobs and integrations: pointing the main interface at a new service does not transfer authority if batch jobs still mutate the old store.

4. Vertical-slice or capability-first

Move one bounded capability end to end: its entry points, rules, state, integrations, observation, and operating procedure. Route requests for that capability to the new system and leave the rest in the old one.

This is often the strongest phased option because the cut line follows a business capability rather than a technical layer. It can produce a real authority transfer: “the new system owns notification preferences” is clearer than “the new system owns some new tables.” It also makes phase exit criteria easier to state.

The path is unsuitable when the proposed slice is not actually bounded. A capability that participates in every transaction, shares mutable records with many workflows, or cannot be routed independently may create more translation and synchronization work than it removes. “Feature-by-feature” is not a license to call an arbitrary screen a feature.

5. Controlled big-bang

Build and rehearse the replacement, stop writes or otherwise establish a controlled boundary, migrate state, change routing, verify, and either continue or roll back according to a runbook.

Big-bang is a reasonable candidate for a small, well-understood system with few integrations, a tolerable maintenance window, reliable backups, deterministic transformation, representative tests, and a rollback that has been rehearsed. It can avoid months of dual operation. AWS’s cutover guidance notes that all-at-once and phased approaches both have valid constraints; it also treats final synchronization, routing changes, validation, and rollback checkpoints as explicit cutover work.

Reject it when the system has uncertain behavior, many external dependencies, high write volume with little downtime tolerance, or recovery that would lose post-cutover transactions. “One weekend” is a duration, not a risk model.

A decision framework for each phase

Do not choose a sequence from a slogan. For every proposed phase, write down the following contract:

These questions are coupled. A rollback plan depends on the authority decision. Verification depends on knowing which differences are acceptable. An exit criterion depends on being able to observe routing and synchronization. If one answer is vague, the apparent safety of the whole phase is partly fictional.

The framework also changes how teams compare plans. A three-month vertical-slice migration with clear authority may be less risky than a six-week interface replacement followed by an undefined period of dual writes. Schedule length matters, but ambiguity duration matters too.

Worked illustration: a scheduling product

The following is an invented illustration, not a case study or proof of outcomes.

Consider a scheduling product used by customers and an operations team. It stores accounts, availability, appointments, payments, and reminder preferences. It exchanges data with payment and calendar providers. Operators can override availability, correct failed imports, and resolve double-booking disputes through an admin workflow.

The team evaluates all five paths.

Data-context-first: accepted as discovery, rejected as the first authority cutover. Profiling the data can identify duplicate customer records, time-zone anomalies, and orphaned appointments. It cannot explain every override or determine whether the calendar provider or an operator decision wins after a conflict. The team uses the findings to define invariants and interview operators, while the old product remains authoritative.

Interface-first: rejected for the first production phase. The customer screens look like a separable surface, but availability and cancellation policy are partly enforced in page workflows. Replacing the interface first would either reproduce undocumented logic or expose incomplete backend contracts. It may become viable after those rules are moved behind tested interfaces.

Backend-first: rejected as a system-wide opening move. The old interface, scheduled reminder job, import process, and admin tooling all write shared records. Replacing the booking service alone would not establish a single booking authority; it would produce several old writers and one new one.

Vertical-slice first: selected for reminder preferences. The slice has a distinct entry point, bounded state, a reversible routing rule, and observable deliveries. During the phase, the old system remains authoritative for appointments, while the new system alone accepts reminder-preference changes. Old preference writes are disabled. Appointment events flow one way to the new reminder capability. Reconciliation checks compare preference ownership and delivery eligibility, and a routing flag can return reads to the old view without pretending that new preference writes never occurred.

The phase exits only after all preference entry points use the new capability, event lag remains within the agreed bound, failed deliveries are visible, operator procedures are updated, and no old process can change preference state. The next slice is chosen only after this authority transfer is complete.

Controlled big-bang: rejected for the whole product because payment, calendar, time-zone, and operator dependencies make a single cutover difficult to verify and costly to reverse after new appointments are accepted. It remains a plausible option for a separate internal reporting utility with one read-only import, no live transactions, and a tested restore procedure.

The illustration does not prove that vertical slicing is universally best. It shows the evaluation method: reject paths whose first phase cannot name one authority and a reversible boundary.

Where AI helps—and where it cannot decide

AI-assisted analysis can reduce the mechanical cost of migration discovery. Given access to relevant evidence, tools can inventory schemas and routes, trace call sites, cluster recurring errors, compare API responses, propose reconciliation queries, draft compatibility adapters, and generate candidate tests from observed behavior. They can also maintain a contradiction list: fields with several meanings, policies that disagree with code, or flows with more than one writer.

These are useful roles because they make evidence easier to inspect. They do not resolve ambiguous product intent. A model cannot reliably infer from a nullable field whether null means “unknown,” “not applicable,” “not yet processed,” or a historical bug without further evidence. It cannot legitimately decide from technical artifacts alone whether an operator workaround is a policy to preserve or debt to remove. It cannot approve an acceptable difference, assign business authority, or declare a cutover safe.

NIST’s Generative AI Profile treats confidently false output—confabulation—as a distinct risk and recommends evaluation and human oversight appropriate to context. That matters in migration work because a plausible explanation of unfamiliar code can be more dangerous than an explicit unknown. AI output should therefore be linked to inspectable evidence and converted into hypotheses, tests, or questions rather than silently promoted to system semantics. (NIST AI 600-1)

Limits and counterexamples

Authority is a useful lens, not the only one. Regulatory constraints, vendor support windows, security exposure, physical infrastructure, contractual deadlines, and organizational ownership can rule out an otherwise elegant sequence. Some distributed systems legitimately have several writers; they need an explicit conflict model rather than a fictional single database. Some migrations are primarily infrastructure relocations and do not change business semantics, so their decisive boundary may be network routing rather than capability ownership.

There are also cases where a long hybrid period is intentional. A platform may support old and new protocols for years, or maintain a compatibility layer as a product commitment. That can be sound if the layer has durable ownership, observability, versioning, and a tested consistency model. The problem is not coexistence itself. The problem is accidental coexistence with temporary assumptions and no expiry decision.

Finally, clean authority does not guarantee a correct target. A team can transfer ownership perfectly and still preserve the wrong policy or build the wrong system. User research, domain judgment, security analysis, performance testing, and operational readiness remain necessary.

The sequence is the architecture because it determines the system people actually run while the diagram is changing. Choose the next phase by asking what authority it transfers, how that transfer can be verified, and how it can be reversed. If those answers are not yet concrete, the next step is discovery—not cutover.