Choose an approach that fits your requirements.
Start with a quick check of offline copy time. Then compare online migration and rollback using measured performance and confirmed capabilities.
Enter the business requirements
These values are shared by both models. Cutover means switching to the new database. Rollback means returning to the existing one.
Estimate the full-copy interruption
Could copying all the data fit within the allowed downtime? Enter explicit assumptions for the complete migration process.
How the Simple model works
Copy time = Data volume / Assumed bulk speed Offline downtime = (Copy time + Other cutover work) × Planning factor Time available for copying = Cutover budget / Planning factor - Other cutover work Required bulk speed = Data volume / Time available for copying If available time is zero or negative: revise the cutover plan. If estimated downtime fits: offline is a candidate. If it exceeds the limit: evaluate online or revise the inputs. Missing or invalid required inputs: unknown.
Evaluate cutover and change capture
Change data capture (CDC) records new source changes and applies them to the target while the source stays in use.
Check the return-to-source plan
After the target accepts writes, it may contain new data the source does not have. Define a separate recovery plan for each approach.
How the Advanced model works
Offline downtime = (Data volume / Bulk speed + Other offline work) × Planning factor CDC spare capacity = CDC capacity - Source change rate CDC must have positive spare capacity to keep up and clear backlog. Online downtime = (Remaining source changes / CDC capacity + Other online work) × Planning factor Rollback downtime = (Target changes to restore / Restore speed + Other rollback work) × Planning factor When there are no target changes to restore, restoration time is zero. For each approach: • Cutover and rollback must fit their time budgets. • Expected data loss must not exceed the allowed limit. • Demonstrated rollback coverage must reach the required period. • Capabilities and a compatible recovery method must be confirmed. • Processing rates must be supported by representative measurements. Known failed requirement: not feasible under these inputs. Otherwise, missing evidence or assumed performance: unknown. All required checks pass with evidence: feasible.
Terms in plain language
Bulk throughput: data read from the source, moved and loaded into the target each minute. Network speed alone does not measure this.
Backlog: changes still waiting to be processed. Include changes not yet captured, not only those in an apply queue.
Planning factor: an allowance for uncertainty. A factor of 1.25 adds 25% to the entire estimated interruption.
Other operational work: stopping writes, completing required readiness checks and switching the application. Include only work during the interruption.
Data-loss limit (RPO): recovery point objective, expressed as minutes of recent committed activity that may be lost. Zero means no loss.
Rollback coverage: how long after cutover the return-to-source procedure must remain available. It is separate from recovery duration.
Network latency: round-trip delay, in milliseconds. Use it as a condition for throughput testing; it does not automatically determine transfer speed.
GB and minutes: one gigabyte is one billion bytes; one terabyte is 1,000 GB. All time budgets here are in minutes.
Scope and assumptions
This models migration cutover and rollback. Ongoing replication additionally requires a target freshness or lag requirement. Online initial loading happens before the final outage; evaluate its duration, retained change logs and storage separately. If export, transfer and import are sequential, use a throughput measurement covering their combined duration. Schema conversion and application changes must also be ready.
Comparisons use full precision. Displayed results are rounded. Examples are planning illustrations, not vendor benchmarks.