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.
Decommissioning is the decision that the old environment will not be used for production rollback or daily operations. It is not the same moment as cutover success on Sunday night. Cutover can succeed while acceptance evidence is still incomplete: integrations untested for a full business cycle, backups on the new side not yet proven, or the old system still the only copy of data nobody has verified.
Acceptance criteria are written before cutover and judged after hypercare. They answer whether the new environment is good enough to retire the old one, not whether Sunday’s smoke test was green.
NIST SP 800-34 separates validation testing (data completeness, functionality) from the later declaration that reconstitution; or, in a migration reading, return to normal operation on the new platform; is complete (NIST SP 800-34 Rev. 1). SP 800-53 control CP-4 expects contingency plan testing, review of results, and corrective action where needed (NIST SP 800-53 Rev. 5; CP-4, printed pages 119–120). Migration acceptance borrows that structure: criteria, review, documented verdict.
Why it matters
Teams decommission early to save cost, or late from fear. Early decommission removes the last quick rollback path. Late decommission pays double hosting and confuses users about which URL or shortcut is correct.
A board without acceptance criteria delegates the decision to whoever is tired on day five of hypercare. That is not governance; it is momentum.
How it works
Write criteria in observable terms
Each criterion should be pass/fail with an evidence artefact:
| Domain | Example criterion | Evidence |
|---|---|---|
| Business function | Payroll submission completes for pay period X | Signed owner checklist |
| Data | Control total or record count matches agreed tolerance | Report export with timestamp |
| Integrations | Each named integration succeeded in production since cutover | Log summary or ticket closure |
| Identity | All required groups and SSO apps work for pilot and full user set | IdP sign-in report |
| Backup/restore | Restore test from new environment backup succeeded | Test record with backup ID |
| Operations | Monitoring alerts routed; on-call roster confirmed | Run sheet |
| Security | Firewall and access rules match approved baseline | Config snapshot or scan |
Avoid “users seem happy”. Use sampled survey or help-desk category thresholds if sentiment matters.
Separate cutover gates from decommission gates
Cutover go/no-go (last-hour checks) proves readiness to switch traffic. Decommission gates prove sustained operation:
- At least N complete business cycles (e.g. two weekly payrolls, one month-end close).
- Zero severity-1 defects remain under the agreed definition, unless a named risk owner explicitly accepts a tested workaround with an expiry and action owner. Unresolved data-integrity or security conditions cannot be waived by an operational workaround alone.
- Backup restore on the new platform, not only backup job success.
- Scheduled jobs catalogue verified on the new environment against the approved inventory.
Who signs acceptance
Name roles, not rooms:
- System or application owner; business function met.
- IT service owner; operability, monitoring, backup evidence.
- Security or risk delegate; access and data handling unchanged or improved per plan.
- Migration sponsor; accepts residual risk and approves decommission date.
This mirrors the separation in recovery assurance articles between “test passed” and “declared back in normal service”. Decommission is closer to the second.
Partial acceptance and deliberate retention
You may accept the new system for production while retaining the old environment read-only or powered off under a tested recovery plan. Record a separate retention decision, including its owner, recovery point, dependencies and expiry.
What to choose and why
Choose fewer, stronger criteria over long laundry lists nobody reads. Ten pass/fail checks with owners beat fifty vague aspirations.
Choose a minimum observation period tied to real cycles, not arbitrary “two weeks”.
Choose to block decommission if the only restorable backup chain for critical data still lives on the old estate.
Risks and limits
Conflating DR test pass with migration acceptance; proving RPO/RTO in a drill does not prove daily operations on the new stack.
Vendor sign-off substituted for owner sign-off; hosting provider readiness is necessary; business acceptance is separate.
Deleting old backups when accepting new. Acceptance must include evidence that the new recovery set restores the required service. ISM PRO-10 calls for regular, secure and proven backups, including validation of restoration capabilities. Acceptance does not itself authorise deletion of older retained records.
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.
- NIST SP 800-34 Rev. 1, May 2010, section 4.4.
- NIST SP 800-53 Rev. 5, September 2020, CP-4.
- ASD ISM, September 2026: cyber security principles, PRO-10.
- ASD ISM, September 2026: system management.
Related future topics
- Hypercare in the first 72 hours after migration.
- Retiring the old environment without deleting the last recovery path.
- Go/no-go criteria before cutover.
Learning notes
- Cutover success and decommission acceptance happen at different times.
- Criteria need pass/fail evidence and named signatories.
- Business cycles matter more than arbitrary waiting periods.
- Restore proof on the new backups is a common missing gate.
- Partial acceptance can still require retaining the old environment for a while.
This article was originally published on .