Deploy-First Runbook (Carbonite Migrate)¶
Step-by-step execution for agent-based OS-level replication from Nutanix to Azure Local using Carbonite Migrate (an OpenText product). See Prerequisites for system requirements, licensing, and expected downtime.
Phase 1 — Provision and baseline the target VM¶
- Create the target Azure Local VM with approved CPU, memory, and storage sizing
- Install the guest OS and apply baseline patching
- Join the target VM to the correct domain or identity boundary
- Apply baseline configuration: security tooling, monitoring agents, and backup policy
- Pre-create data volumes and mount points to match the application design
- Confirm IP, DNS, firewall, and service account requirements with the application owner
- Do not install the application yet — Carbonite will replicate it from the source
Phase 2 — Install Carbonite Migrate agents¶
- Log on to the Carbonite management server
- Download the Carbonite Migrate agent installer for the source VM OS family (Windows or Linux)
- Install the Carbonite Migrate agent on the source Nutanix VM per Carbonite's agent installation guide
- Install the Carbonite Migrate agent on the target Azure Local VM
- Verify both agents appear as online in the Carbonite management console
- Confirm TCP ports
6325and6326are reachable between source and target agent endpoints
Phase 3 — Create the migration job¶
- In the Carbonite management console, create a new migration job
- Set the source to the source Nutanix VM agent endpoint
- Set the target to the target Azure Local VM agent endpoint
- Configure the replication scope — include all required volumes; exclude temp/cache paths where appropriate
- Configure cutover settings: re-IP rules, DNS update behavior, and pre/post cutover scripts if required
- Review job settings with the application owner before starting replication
Phase 4 — Initial mirror¶
Phase 4 has zero downtime — source VM stays online
The initial mirror is a full block-level copy that runs in the background. The source Nutanix VM continues serving workloads during this phase. Do not schedule a maintenance window for the initial mirror.
- Start the migration job in the Carbonite console
- Monitor the initial mirror progress — this is a full block-level copy and may take several hours depending on data volume
- Confirm mirror completion is reported healthy in the console
- Do not schedule cutover until the initial mirror has completed and continuous replication is active
Phase 5 — Continuous replication and pre-cutover validation¶
- Confirm continuous replication is running and the delta queue is staying current
- Monitor replication lag — lag should be consistently low before scheduling cutover
- Perform a test cutover (non-production) if permitted:
- Initiate a test failover in the Carbonite console
- Validate application functionality on the target VM
- Revert the test failover and confirm replication resumes
- Schedule the production cutover window with the application owner and change management
Phase 6 — Production cutover¶
Downtime begins here
Typical service disruption: 5–30 minutes (time from quiescing source writes to target serving traffic). In optimal conditions (low replication lag, fast storage) expect 5–15 minutes. Confirm replication lag is low before initiating cutover.
- Notify all stakeholders that the cutover window is active
- Quiesce or redirect source application traffic to maintenance mode
- In the Carbonite console, initiate the production cutover:
- Carbonite stops source writes
- Final changed-block sync completes
- Workload execution transfers to the target Azure Local VM
- Confirm the target VM is serving the workload correctly
Phase 7 — Post-cutover validation¶
- Application owner runs smoke tests on the target VM
- Validate DNS resolution, IP addressing, and gateway connectivity
- Confirm monitoring and alerting baselines are active on the target VM
- Verify scheduled tasks, services, and any application-specific startup items
Cutover checklist¶
- [ ] Continuous replication confirmed healthy and lag is low
- [ ] Test cutover completed and reverted (if applicable)
- [ ] Application owner present for production cutover
- [ ] Change management window active
- [ ] Source writes quiesced before final sync
- [ ] Final Carbonite sync confirmed complete before declaring cutover done
- [ ] DNS / load balancer entries updated
- [ ] Target application healthy before user traffic restored
Cleanup¶
- Keep the Nutanix source VM powered off or isolated during the hold period (minimum 5 business days recommended)
- Document final target IP, DNS, and service configuration
- Remove Carbonite agent from source and target once the rollback window is closed
- Remove the migration job from the Carbonite console
- Decommission the Nutanix source only after written sign-off from the application owner and rollback window closure