About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not lab validation. Check the stated versions and your own requirements before making changes.
Big-bang cutover moves production to the new environment in one controlled window: users stop on the old system, data is brought current, validation runs, and traffic switches. Parallel run keeps old and new live for a period, with rules for which system is authoritative and how differences are detected and resolved.
The choice is a strategy decision. Cutover runbooks describe how to execute a window; they do not decide whether you need two live ledgers for a fortnight.
NIST SP 800-34 describes concurrent processing as running a system at two locations until there is assurance the recovered or relocated system operates correctly and securely, followed by validation and a declaration that reconstitution is complete (NIST SP 800-34 Rev. 1). Planned migration can borrow that pattern when risk warrants dual operation; but NIST’s example is assurance after disruption, not a licence to run two production writers indefinitely without reconciliation design.
Why it matters
Line-of-business applications such as ERP, practice management, payroll and inventory depend on accurate records for financial transactions and compliance reporting. A wrong cutover model shows up as duplicated invoices, lost timesheets, or reports that disagree with the bank.
Big-bang minimises dual-maintenance cost and avoids long periods of ambiguous authority. Parallel run buys time to compare outputs and train staff, at the price of consistency work, double licensing, and operational complexity.
How it works
When big-bang is usually enough
Consider big-bang when:
- Dependencies are bounded and rehearsed, with a tested rollback story.
- Data volume and change rate allow a defined freeze and final sync within the window.
- Users can tolerate a stated outage or read-only period.
- The vendor supports a single production instance and does not require extended dual-live operation.
Big-bang fails organisationally when the business cannot honour a freeze, when integrations feed continuously from unfrozen partners, or when validation truly needs side-by-side business outputs.
When parallel run is worth the cost
Consider parallel run when:
- Regulatory or audit requirements demand comparison of old and new outputs for a period.
- The application has many batch chains whose behaviour is only visible over weeks.
- User retraining benefits from optional access to the old system while learning the new path.
- Risk appetite forbids a single irreversible switch without live corroboration.
Parallel run is not “run two production databases and hope”. It requires:
- Single writer rule; only one system accepts authoritative transactions unless a documented merge process exists.
- Reconciliation; scheduled comparison of balances, document counts, or control totals, with named owners for discrepancies.
- Exit criteria; calendar and metric-based end to parallel run, not “when everyone feels ready”.
Hybrid patterns
Common compromises for hosted Windows line-of-business stacks:
| Pattern | What runs twice | Authority | Typical duration |
|---|---|---|---|
| Read-only old + live new | Old system query-only | New | Days to one pay cycle |
| New live, old batch reader | Old jobs may read an agreed export | New owns writes; old jobs cannot write production records or repeat external actions | Illustrative: one to two tested batch cycles |
| Pilot by partition | Explicitly separated sites or datasets | One writer per partition; shared records require supported synchronisation and reconciliation | Until agreed pilot acceptance |
Record authority for every shared dataset and external effect, including invoices, payment exports, emails and scheduled jobs. A user group is not automatically a data boundary. If ownership cannot be separated, use a read-only comparison or a vendor-supported, rehearsed synchronisation design. Define discrepancy handling and exit evidence before dual operation starts.
Cost and risk trade-off
Parallel run costs hosting, licences, staff time, and reconciliation tooling. Big-bang costs concentrated outage risk and a harder rollback if validation fails late.
Consistency risk in parallel run rises when:
- Integrations write to both sides.
- Scheduled jobs are not inventoried post-migration against the approved job inventory.
- Staff continue data entry on the old system “because it is faster today”.
What to choose and why
Consider a big-bang cutover when rehearsal, owner availability and the permitted write outage support it. Confirm that the tested recovery path covers the actual data-authority boundary.
Choose parallel run when evidence must accumulate over real business cycles, not when the team simply fears cutover night. Fear is a reason to improve rehearsal and go/no-go gates, not automatically to double production.
Choose read-only old as a lightweight parallel pattern when training and audit comparison matter but dual-write does not.
Document the choice in the migration board minutes with: authority model, reconciliation method, parallel-run exit criteria, and decommission trigger for the old environment.
Risks and limits
Parallel run without single writer; diverging data with no merge plan is two productions, not a migration strategy.
Big-bang without rollback depth; if rollback cannot recover writes made on the new side, you have chosen an irreversible model; say so explicitly.
Vendor silence; some applications forbid two live copies; licence terms must be checked before parallel run.
This article does not replace cutover mechanics (replication proof, DNS, gates). It does not describe hosted migration delivery steps.
Sources
Developed with AI assistance. Source research only; no migration, recovery or infrastructure procedure was executed or lab validated.
Source research accessed 14 November 2026. These documents support the stated principles and tool-specific conditions; the planning templates are editorial recommendations.
Related future topics
- Acceptance criteria before decommissioning the old system.
- Designing a pilot that predicts production risk.
- Retiring the old environment without deleting the last recovery path.
Learning notes
- Big-bang trades outage concentration for simpler authority; parallel run trades cost for comparison time.
- Parallel run needs a single writer rule and reconciliation, not two favourite systems.
- NIST concurrent processing is an assurance pattern, not unlimited dual production.
- Hybrid read-only old is often enough for training without dual-write risk.
- Document authority, exit criteria and decommission triggers when the board chooses the model.
This article was originally published on .