Transfer and deploy a wave

This tutorial starts after assessment acceptance and conversion. You should already have an engagement, estate, accepted objects, verified connections, and immutable converted artifacts.

The end-to-end path

Follow these developer guides in order:

1. Build a resumable data transfer to create a transfer specification, plan scope, run, pause/resume, and reconcile.
2. Deploy with Fabric Runway to register a deployment manifest, request the desired state, and observe the Runway result.
3. Validation to record independent data and business evidence.
4. Cutover only after the required readiness tracks pass.

Read the deployment page before you act

The Requirements, Awaiting observation, Matched, and Blocked or uncertain counters describe a reconciliation workflow; they are not deployment-job counts. Four zeros mean that no desired release has been declared for the selected engagement.

Choose Create the first deployment requirement and select the exact immutable artifacts that form the release. For a normal first release, choose Deploy a new release, the environment where validation will run, and Release succeeded. Airlift computes the desired digest; it does not deploy the artifacts itself.

The next-action card then gives you the exact fr deploy command. Run it from the Runway artifact directory, copy the returned deployment ID and staged artifact SHA-256, and choose Connect Runway deployment. The connection is only a pointer. Choose Check Runway result now to make admitted automation query Runway and independently verify the release.

After Runway executes the release, Airlift admits the verified release reference and compares artifact digest, environment, operation, and terminal state. A match unlocks validation. Missing or different evidence remains awaiting, blocked, or uncertain with a plain-language next action. If verification is disabled, configure the Runway observer; do not interpret the disabled button as a successful deployment.

See Follow the guided migration journey for every phase screen and its evidence semantics.

What to automate in CI

fa transfer status "$TRANSFER_ID" --json > transfer-status.json
fa deployment status "$DEPLOYMENT_REQUIREMENT_ID" --json > deployment-status.json

Fail your release when the transfer is not completed, the deployment reconciliation outcome is not matched, or a required readiness track is stale. Do not infer readiness from a job exit code.

What to test regularly

• duplicate transfer starts attach to one Temporal execution;
• restart resumes from the latest increasing checkpoint;
• pause is respected without losing an in-flight checkpoint;
• excessive lag and row-count mismatch fail reconciliation;
• a person cannot record runner or Runway evidence;
• deployment digest drift blocks readiness;
• unknown actual state remains uncertain; and
• all governed action replays collapse under the same idempotency key.