At the US model's $185 blended project rate, a 50% project gross-margin target leaves $185 × 0.50 = $92.50 of delivery-cost allowance per quoted labor hour. A cloud migration plan needs to fund the preparation and recovery work as well as the move. Estimate that scope before promising a cutover window.
Gross margin is project revenue less its direct delivery cost, divided by project revenue. The rate doesn't establish how many hours a workload needs. Use the dependency assessment and rehearsal evidence to estimate the actual work, including any specialist support.
Move the Client's Working Service
Begin with the business task the client needs to perform after migration. Identify the application owner who can demonstrate it and the dependencies that make it possible. Starting a destination server doesn't establish that a transaction reaches the right place.
Record the prerequisite for each move and which components must move together. Get the application's maintainer involved before promising that an infrastructure change covers the application work. Keep an unresolved dependency in the readiness decision rather than hiding it behind a migration label.
In a vendor-qualified podcast discussion, George, introduced as Synetec's CEO, describes public-cloud infrastructure provision leaving bespoke-application migration unresolved. He recommends suitable development expertise or a partner. I'd put that scope question to the project lead before assuming the engineer handling the host can also adapt the application.
I don't buy a growth-hack pitch that makes a difficult handoff disappear by calling it transformation. Describe the action the client must complete and what demonstrates success. An acceptance condition should be something the named approver can actually check.
Rehearse the Move and Its Recovery
Test the chosen migration method before booking its production window. Record missing access and the steps that take time. Explain differences between the rehearsal and the planned workload so the decision lead knows which results can be relied on.
Where final synchronization is required, establish how the application reaches a consistent state. Agree what activity must stop and who can authorize that interruption. Don't assume the workload can continue accepting writes throughout the method you've chosen.
Run the recovery procedure too. Record the restoration work and the application verification needed before users can resume. A console showing a backup exists isn't the same evidence as a successful workload recovery test.
The calendar has no restore button. Fit the measured recovery and verification work inside the client's required restoration window before committing to a cutover. If it won't fit, change the design or agree another window rather than assuming the recovery will be quicker in production.
Assign Each Checkpoint Before the Night
Use the following as a proposed runbook structure. A runbook is the ordered record of steps, owners, checks, and stop conditions for the move. Put individual names against the roles in the live version and confirm that each person accepts the assignment.
| Checkpoint | Accountable Owner | Evidence to Have |
|---|---|---|
| Dependencies ready | Project lead | Prerequisites complete and move order checked with the application maintainer |
| Business acceptance ready | Client process owner | An authorized tester and observable pass condition for the business task |
| Recovery ready | Recovery engineer | Tested procedure and measured restoration and verification work |
| Data handling agreed | Application or data owner | Authoritative system at each stage and a supported handling of later writes |
| Proceed or stop | Decision lead | Readiness results, explicit exceptions, and a reachable client approver |
| Client updates ready | Service coordinator | Approved communication route and named update owner |
| Support handover ready | Service desk lead | Checked access and service records, with remaining project work assigned |
Give each execution step its own observed result and condition for continuing. A failed check needs a named decision, not an assumption that the next step will repair it. Confirm supplier contacts where the plan depends on their help.
Decide What Happens to New Data
After users begin working on the destination, a return to the old host can leave their new records behind. Have the application maintainer and data owner define a supported recovery and reconciliation method before that point. Record when each system is authoritative and who approves changing that state.
The method may require recovery on the destination instead of a simple return to the source. Don't improvise simultaneous writes to both systems to make the design sound reversible. Test the chosen approach and how the owner will confirm the records are consistent before reopening the service.
An engineer's access to both environments doesn't authorize discarding business data. If the rehearsal leaves the data decision unresolved, keep the design open. Obtain the required decision before treating the return path as usable.
Calculate the Latest Decision From the Test
Start with the client's required restoration point and subtract the tested recovery and verification duration. The result is the latest decision point on that measured basis. Allow for the specific uncertainty the rehearsal identified, then check whether enough time remains to validate the destination.
The model supplies no outage duration or standard recovery allowance to insert into that calculation. Use your workload's measured times and the client's approved requirement. Record the actual result in the runbook so the decision lead has a usable time rather than a formula to solve during an incident.
At the checkpoint, compare the observed result with the agreed acceptance condition. An unknown outcome stays unresolved. Have the decision lead consider the remaining time and current data state before authorizing continued recovery or a return to the source.
Fund the Scope and Finish the Handover
Multiply the scoped billable hours by $185 to calculate labor revenue at the model's blended rate. At the 50% target, the delivery-cost allowance is that revenue multiplied by 0.50. Compare the actual direct delivery estimate with the allowance, including the rehearsal and recovery preparation you've committed to perform.
The $92.50 per quoted-hour allowance is a pricing calculation, not the technician's wage or a universal estimate of migration effort. Include specialist costs where required and identify any scope outside the estimate. Don't sell an optimistic hour count and leave the team to discover the missing work at cutover.
When the desk opens on Monday morning, can it access the changed service and identify who owns each remaining issue? Check that before the project team signs off. Keep remediation assigned to the project rather than allowing it to become unexplained work in the support queue.
For the next proposed move, have the project lead bring the dependency record and recovery-test evidence to the window decision. Ask the client process owner to confirm the acceptance task there. Book the window when the named owners can explain both the successful handover and the response to failed acceptance.
mspoutpost.com/articles/cloud-migration-plan-own-the-cutover-and-the-way-back
Written by Megan Friesen
MSP Outpost publishes information, not legal, financial, insurance, tax or compliance advice, and reading it creates no professional relationship. For decisions about your business, talk to a qualified professional.