Plan an application migration as a series of workflows

A plan is not a migrator

Be clear about the split before anything else. OCNORA plans and orchestrates an application migration. It does not convert, re-platform or move an application itself. That work is done by the tools and teams you already have: deploy pipelines, data transfer jobs, infrastructure scripts. The workflow calls them over HTTP or as sub-workflows, decides the order they run in, and records what each one returned.

The split matters because migrations tend to go wrong between the tools rather than inside them. A dependency nobody listed. A test suite that ran against the old environment. A cutover that went ahead because nobody was asked. A rollback owner who found out they owned it halfway through. Orchestration is for those gaps: the order of steps, the checks that gate the next one, the person who approves, and a record you can read afterwards.

Start with an inventory and dependency checks

The inventory is the input every later step reads: each application in scope, its owner, what it depends on and where its data lives. Keep it as a step in the workflow, not as a spreadsheet next to it. Then the plan the checks ran against is the plan on the record, and a change to it is a change someone can see.

Dependency checks come next, and they run against the target, not the source. For each dependency the inventory lists, an HTTP request asks whether it answers from where the application will live: the database accepts a connection, the queue is reachable, the downstream API answers with the credential the target will use. A branch reads the results. A failing check stops the run with its output rather than letting it carry on.

inventory   (illustrative, synthetic data)

  application     owner          depends on              data store
  billing-api     payments team  ledger-db, rates-queue  ledger-db
  invoice-worker  payments team  rates-queue, mail-api   none
  customer-web    web team       billing-api             sessions-cache

  dependency check against the target, per row:
  ledger-db     reachable     ok
  rates-queue   reachable     ok
  mail-api      credential    rejected  → run stops here

Rehearse with integration tests before data moves

Run the plan before you run the migration. A rehearsal is the same workflow stopped before the transfer: inventory, dependency checks, then the integration tests against the target environment. Call your existing test suite as a sub-workflow or over HTTP, let a branch read the result, and repeat the rehearsal until it passes. No data has moved, so a failure here costs a rerun and nothing else.

Checks catch what they test. A target that passes weak integration tests can still fail at cutover, and a green rehearsal is only as good as the list of things it tried. Write that list with the application owners, not for them. They know which path breaks on a Monday morning; the test suite may not.

Transfer, then validate the target

The transfer is your own job, called by the workflow. Each step has its own retries and timeout, and a step that still fails is kept on the run with its input and error, so a stalled transfer is something you read rather than reconstruct. If the move includes records from a CSV export into a SQL table, the data migration solution covers that part in detail.

Validation reads the target back. Ordinary SQL query steps compare counts and checksums with the source and read a known record to check it arrived whole. A query step fails rather than return more rows than its limit, so write these checks as aggregates, not as full reads compared row by row. The results sit on the run, beside the transfer that produced them.

migration run   (orchestration pattern)

  inventory ─▶ dependency checks ─▶ integration tests
                                          │
                     ┌────────────────────┘
                     ▼
               transfer data ─▶ validate the target
                                          │
                                    cutover gate
                                   (person approves)
                                  ┌───────┴───────┐
                              approve            decline
                                  ▼               ▼
                              cut over      rollback owner
                                  └───────┬───────┘
                                          ▼
                                  report the outcome

A cutover gate and a rollback someone owns

Cutover is a decision, so a person makes it. An approval step suspends the run until the named approver answers or its timeout lapses, and the approver sees the dependency, test and validation results before they choose. The answer is recorded with the run. Decide in advance what a lapsed timeout means for your migration, and write it down: a gate nobody answers should not become a cutover by default.

When validation fails or the approver says no, the run goes to the rollback owner. OCNORA does not undo a migration on its own. Rollback means your own plan, backup or reverse script, run by the person who decides it. Name that person before the run starts, and take the backup before the transfer, not after the first surprise.

1. Write the inventory with owners, dependencies and data stores.
2. Rehearse: dependency checks and integration tests against the target, until they pass.
3. Name the cutover approver and the rollback owner; take the backup.
4. Run the transfer and the validation queries.
5. Let the approver decide, with the results in front of them.
6. Cut over, or hand the run to the rollback owner, and report either way.

Prerequisites, limitations and a next step

• Prerequisites: an inventory of the applications in scope, with an owner, dependencies and data stores for each; the migration tooling you already use, reachable over HTTP or as workflows; integration tests and validation queries that say whether the target works, runnable before cutover; a named approver for the cutover gate and a named rollback owner, with a rollback plan and a backup taken before the run.

• OCNORA plans and orchestrates the migration. It does not convert, re-platform or move applications; the tools and teams the workflow calls do.
• The workflow above is an orchestration pattern, not a template in the library. You assemble it from the steps shown and test it against your own environment.
• OCNORA does not roll back a migration. Rollback is your plan, run by its owner.
• We publish no duration, success-rate or downtime figure for migrations.

The application migration solution sets out the full workflow, step by step, with its prerequisites and limitations. The cutover gate is built from the same pattern as the approval-gate template. If you want to map your own migration onto it, book a demo: we start from your inventory, place the checks and tests you already have, and agree where the gate sits and who owns the rollback.