Upgrading Sitecore XP 10.4 to 10.5: A Production Migration Runbook

A Sitecore upgrade becomes a production migration when people must decide what happens to live traffic, authoring changes, collected interactions, and queued work while the platform changes underneath them. A successful installer does not answer those questions. Neither does a healthy home page. The runbook has to connect the technical upgrade procedure to a recoverable business decision.

This guide proposes an operational runbook for moving an on-premises Sitecore XP 10.4 solution to 10.5. It follows the vendor’s database-upgrade and side-by-side installation model, then adds explicit ownership, evidence, and stop conditions. The detailed SQL instructions remain in the official guide because their applicability depends on the source version and database role. Treat the control records and acceptance examples below as templates to adapt, rather than a report of an upgrade that I performed on your environment.

The short answer is: inventory the actual estate, rehearse against isolated copies, protect a restorable recovery point, upgrade the applicable databases, install a clean target beside the existing installation, deploy a rebuilt solution, complete post-upgrade work, and move traffic only after the agreed gates pass. Sitecore documents the overall sequence in its 10.5 upgrade guide introduction. Container and Azure deployments need their own deployment instructions; this article does not turn the on-premises guide into a universal hosting procedure.

My preference is to make the recovery boundary the central design artifact. That means choosing exactly which application build, databases, search configuration, and external integration state can be restored together. Another team might prioritize the shortest cutover. I would accept a longer, rehearsed window before accepting a shorter window with an untested return path. No downtime estimate or performance improvement in this article is presented as a measured result.

1. Define the migration contract and prove the target

Record the starting point precisely

Begin with a release record that another engineer can reconstruct without asking the original author. Write down whether the source is 10.4.0 or 10.4.1, the deployed build identifiers, topology, enabled XP features, hosting pattern, installed modules, and deployment mechanism. Add the commit and artifact that produced the application currently serving traffic. A branch name alone is inadequate because its contents can move while the migration is being rehearsed.

For each environment, list the CM and CD applications, xConnect roles, background services, database connections, search endpoints, authentication dependencies, certificates, and scheduled integrations. Include custom databases and indexes. The inventory should describe what is actually deployed, including exceptions that never made it back into infrastructure code. Where the record and the running environment disagree, resolve that disagreement before using the inventory to estimate work.

Use a dependency ledger with an owner, current state, target state, supporting source, verification method, and disposition. A disposition can be upgrade, replace, remove, retain, or investigate. Avoid a generic “compatible” checkbox. For a connector, compatibility might mean that the supplier supports the exact combination, the package installs, the application starts, and the business transaction still produces the expected result. Those are separate pieces of evidence with different owners.

Make prerequisites a gate rather than a calendar assumption

Review the 10.5 release resources and the applicable installation requirements before selecting the target infrastructure. That release page also carries a module compatibility notice. Do not infer support for an extension merely because the core platform is available. Record the date of each compatibility check so that a later reviewer can distinguish an outdated assumption from a current supplier statement.

At the time of this review, Sitecore’s breaking-change documentation requires Solr 10 for XP 10.5 and describes changes to search configuration, schema behavior, and custom helpers. See the official breaking changes. In this runbook, that dependency is a prerequisite workstream, with its own acceptance evidence. It is not an incidental image-tag change to squeeze into the final application deployment.

Keep platform support and implementation readiness separate. A supported operating system does not prove that your build agents have the prerequisites needed by your custom solution. A supported SQL version does not prove that the target accounts can reach every required database. Ask the infrastructure owner to demonstrate the actual path from the intended application identity to the intended dependency. This is an acceptance exercise, not a request to grant broad access temporarily and remember to narrow it later.

Define what the migration is allowed to change

Write an explicit scope boundary. The upgrade should have a clear answer for unrelated feature work, content-model redesign, third-party package replacements, and deployment-system changes. My default is to defer unrelated work because it increases the number of explanations for a failure. When a dependency replacement is unavoidable, keep it in scope with an identified test and a reason. The point is to preserve diagnosability rather than to pretend that upgrades happen in isolation.

Agree on the business freeze and availability objectives before allocating the window. Define which user journeys must remain available, whether authoring will stop, how scheduled jobs will be handled, and who decides when service is acceptable. Use environment-specific measurements from rehearsal to populate the timetable. Do not borrow a duration from another installation whose database size, infrastructure, integrations, and validation requirements differ from yours.

Create a compact operation record for every consequential step. The fields should include step identifier, operator, reviewer, prerequisites, exact artifact or procedure reference, expected result, evidence location, maximum permitted elapsed time, and stop action. A maximum duration is a locally chosen control, not a Sitecore product limit. Its purpose is to prevent an apparently harmless delay from consuming the time reserved for recovery.

step: DB-030
owner: database-operator
reviewer: release-lead
input: approved-upgrade-package-and-database-map
precondition: isolated-copies-confirmed
expected: applicable-operation-completed-and-verified
evidence: release-record/DB-030/
on_failure: stop-and-preserve-logs
duration_limit: set-from-rehearsal

The exit condition for this phase is a signed migration contract: exact starting point, supported target, dependency dispositions, acceptance criteria, and accountable owners. An unresolved critical dependency is a reason to stop planning a production date. It is cheaper to discover that uncertainty here than after the content freeze has begun and the recovery clock is running.

Use evidence that survives the meeting

Give each evidence record a stable location and a meaningful identifier. For example, attach the dependency map, package hashes, source database inventory, and test outcomes to the same release record rather than leaving them in individual engineers’ download folders. If evidence contains sensitive connection information, apply the storage controls your organization already uses. The runbook needs a reference to the protected record, not a copied password or a public screenshot of a secret.

Define who can change the approved procedure after rehearsal. A small edit to a database name is different from replacing an upgrade package, changing the source release, or introducing a new module. In this proposed process, the release lead classifies the change and identifies the evidence that must be repeated. That rule prevents an approved runbook from becoming a moving document whose final version has never been executed as a whole.

Review the inventory with people who own business processes, not only the platform engineers. A monthly integration, an infrequently used custom report, or a scheduled campaign can be absent from a brief technical smoke test. Ask owners to identify the next time their process will run and how the team can verify it safely before that date. Add any deferred observation to handover with an owner and a deadline.

Choose a reproducible validation sample

A useful sample is deliberate. Include content with multiple language versions if the solution uses them, content behind the relevant permission boundary, media in the storage pattern the application actually uses, and a representative publishing transition. Describe why each item is in the sample. That explanation helps reviewers see a coverage gap and helps future operators replace an unavailable item without accidentally removing the behavior the test was supposed to exercise.

For a comparison, record both the expected business outcome and the evidence collected from each release. A changed internal identifier or log message does not necessarily mean the business result is wrong; a matching HTTP status does not necessarily mean it is right. Decide what must remain equivalent and what may change with the upgrade. The application owner should approve intentional behavior changes before the production window, while there is time to update tests and communication.

Keep the test data lifecycle explicit. Name who creates the sample, how production-sensitive data is excluded or protected, and how test mutations are cleaned up. A repeated rehearsal should begin from a known starting point rather than inheriting whatever the previous attempt left behind. When restoring fresh copies is the chosen reset mechanism, include that reset in the rehearsal timetable and recovery-access checks instead of assuming it will be available on demand.

Finally, require a concise evidence review before closing each gate. The reviewer should be able to state what ran, against which resources, with which artifact, and what result established success. If the record cannot answer those questions, the team has an evidence gap even when the operator remembers that everything looked normal. Resolve that gap while the environment and participants are still available.

2. Build a restorable recovery boundary

Decide which state must travel together

Start the backup design with a state map. For each database, media store, application artifact, certificate, configuration source, and external queue, describe whether it is authoritative, derived, or managed outside the platform. This classification is a proposed operational aid. It helps the team ask whether a recovery point is complete and whether data created after that point can be preserved. Do not use it to discard data simply because rebuilding something sounds plausible.

Ask the business owner what loss is acceptable for each category. A content freeze might protect authored changes while interactions or external submissions continue elsewhere. A separate application could still write to an integration database even after the public website enters maintenance mode. Record those writers explicitly. The goal is to know which activity stops, which activity is buffered, and which activity requires reconciliation if the migration returns to the previous release.

Sitecore’s database safeguarding instructions require databases to be unused during upgrade scripts. The documented approaches are to upgrade copies or disable the environment, including applicable application roles and services. Make that safeguard an observable precondition. “We put the website into maintenance” does not establish that background writers or another application have stopped.

Rehearse restoration with the recovery operator

Use the backup and restore procedures approved by your database and storage owners. This article intentionally does not invent a universal SQL command because deployment architecture, encryption, backup policy, and recovery requirements are environment-specific. The runbook must point to the exact approved procedure and identify the recovery set it creates. Include the credentials and key-access process needed during an incident without putting secrets directly into the runbook.

Have the person expected to perform recovery restore the selected set into an isolated environment. Verify that restored applications reference restored dependencies rather than production ones. Then test representative reads and writes using safe test accounts. A restored file or successful database restore message is one layer of evidence; successful application behavior on the restored estate is another. Keep both so that the recovery plan has a technical and a functional basis.

Measure restoration in the conditions you expect to have during the production window. Record the time spent locating backups, obtaining access, transferring data, restoring, reconnecting applications, warming essential paths, and performing acceptance checks. The aggregate matters more than the database engine’s restore duration alone. If the plan depends on a person or permission that is unavailable overnight, address that before calling the recovery rehearsal successful.

Protect copies from accidental production side effects

A copied environment should not be allowed to send production email, invoke real payment operations, publish to live targets, or consume production work unless that behavior is explicitly intended and controlled. Build an isolation checklist covering network egress, endpoint replacements, job execution, and credentials. These are proposed controls to adapt with your integration owners. Their value is that they turn “non-production” from a label into a set of tested restrictions.

Review copied collection databases with particular care. The safeguarding page links to additional instructions for configuring Collection after copying. Follow that linked procedure for the actual estate instead of assuming that changing a single connection string completes the copy. Keep the database-name and endpoint mapping in the evidence packet. A reviewer should be able to trace each copied dependency to its intended isolated destination.

Keep the old application’s deployment artifacts available, including environment configuration references and the means to recover required certificates. Verify retrieval before the maintenance window. A rollback procedure that requires rebuilding an old commit against a changed package feed is a weaker recovery option than a preserved, identified release artifact. If preserving an artifact is impossible, document and rehearse the rebuild path as part of recovery rather than treating it as an administrative detail.

Set the last safe decision time

Calculate the latest point at which the team can choose recovery while still meeting the agreed service objective. Use measured rehearsal durations plus an explicit margin selected by the release owner. Do not treat this as a product formula or a guarantee. It is a planning constraint that forces the cutover owner to reserve recovery time instead of spending the entire window attempting another repair.

The recovery record should state what happens to writes after the selected restore point. If the new platform accepts a form submission and the team later restores older databases, explain how that submission is retained, reconciled, or handled through a documented business process. Some external effects may require compensation rather than restoration. Assign that decision to the integration owner; do not imply that a database rollback automatically reverses an external transaction.

This phase passes when the recovery set is identified, restoration has been demonstrated, isolated copies are verified, active writers are accounted for, and the last safe decision time is agreed. A backup existence check alone should not pass this gate. The deliverable is a usable recovery route with evidence, owners, and known limits.

3. Upgrade the database estate on isolated copies

Build a database action matrix before executing scripts

Create one row per actual database, rather than one row per database name you remember from a standard topology. Record the logical role, physical instance, database name, source version, applicable official operation, execution owner, and validation method. Include separate security storage where present and every Collection shard. Keep a reason for rows marked no action. That reason matters when a later operator wonders whether a database was accidentally omitted.

The database upgrade overview says that changes are applied once per database and that instructions can require a particular sequence or manual actions. Use the source-version tables to select work. Do not run every script in the download because it is present, and do not repeatedly execute a failed operation without first determining what state the database reached.

For the XM portion of an XP estate, consult the official XM database matrix. Its 10.1–10.4 source column assigns CMS_master.sql to Master, lists no action for Web and Experience Forms, and makes CMS_security.sql placement depend on whether security is separate from Core. This is a concrete reason to resolve the connection mapping before execution. Do not translate “no action” into permission to skip connectivity and functional validation.

Keep tooling scopes distinct

The UpdateApp 1.5.2 release page identifies packages for specific source versions and XP or XM topologies, and describes the tool’s Core, Master, and Web scope. Select the package that matches the recorded starting point. Do not present that selection as a replacement for the separate database-script and post-upgrade instructions. Each operation should have its own evidence and a clear role in the matrix.

Download the approved resources before the production window, preserve their provenance, and calculate file hashes as release evidence. The following PowerShell example is an inventory operation on an approved package path. Replace the path with the file selected through the official release resources. The hash records which bytes were approved; it does not establish vendor authenticity by itself and should not replace provenance checks.

Get-FileHash -LiteralPath 'D:\ApprovedRelease\DatabaseUpgradeScripts.zip' -Algorithm SHA256
Get-FileHash -LiteralPath 'D:\ApprovedRelease\Sitecore.UpdateApp.zip' -Algorithm SHA256

Rehearse the same package and sequence you intend to use in production. Preserve execution output and the database action matrix together. If the rehearsal produces an exception, record the root cause, approved remediation, and whether the entire procedure was rerun from fresh copies. A runbook made from the happy path of one attempt and the fixes from another can hide dependencies that never worked in a single end-to-end execution.

Apply the XP-specific decisions explicitly

For XP, the 9.0-and-later xDB matrix has a 10.4 source column. Many roles are marked no action. Messaging has SXP_Messaging.sql, with an exception when Azure Service Bus is used. Treat that matrix as the starting point for source-specific work and inspect the accompanying notes. Do not import instructions for older source versions merely because they appear farther down the same page.

Distinguish the logical status of a database from the state of its consumers. A role with no required schema operation still needs the correct connection, permissions, certificate trust where relevant, and a functional check after the new application starts. The matrix should therefore have separate columns for upgrade action and post-upgrade verification. Combining them into one completed checkbox makes it difficult to see what was actually proven.

Write the expected result before running an operation. For a script, that might include successful completion, preserved output, and the specific verification directed by the procedure. For a tool, it might include the documented completion state and subsequent application checks. Avoid using total row counts as a universal success criterion. Counts can be useful evidence for a chosen comparison, but a matching count does not prove that permissions, relationships, or application behavior remain correct.

Define a failed-operation procedure

When an operation fails, stop the sequence and preserve the output before making changes. Identify which database and package were used, whether the failure occurred before or after any mutations, and whether the vendor procedure documents a retry path. Ask the database owner to assess the resulting state. If the state cannot be established confidently, restoring fresh copies and replaying the approved procedure may be the more defensible rehearsal route.

Keep exceptions visible to the release lead. An engineer might be able to make a test environment start after an improvised repair, but that does not make the repair appropriate for production. Require a written explanation, evidence that the repair addresses the cause, and a repeatable sequence that includes it. If supplier guidance is needed, obtain it before scheduling the production attempt rather than relying on an unresolved incident note.

The database gate passes when every row has an explicit disposition, the applicable operations have completed on isolated copies, and validation evidence exists. Preserve the pre-upgrade recovery set. Do not delete it simply because the new application has not yet reported a database error. The next phase still has to prove that the deployed solution can use the upgraded estate correctly.

4. Install side by side and deploy the rebuilt solution

Establish a clean target baseline

Follow the applicable installation guide to create the new instance beside the existing estate, and follow module-specific installation instructions for each approved extension. Sitecore separates that work in Install a new instance. Capture the clean target’s configuration and deployment manifest before adding custom code. That snapshot gives you a meaningful comparison when a later failure could have come from either the platform installation or the application deployment.

Use the approved database mapping when connecting the target. Require an operator and reviewer to check destinations before the first application startup. During rehearsal, those destinations should be the intended isolated copies. During production, they should be the databases selected by the cutover procedure. A side-by-side application installation does not itself prevent both releases from pointing to the same writable dependency, so the connection review needs its own evidence.

Make identity, certificate, and service-account configuration part of the target acceptance. Record how operators retrieve the required material and how the application identity accesses it. Verify expiry and trust through the actual application path. Avoid treating an administrator’s successful connection test as proof that the runtime identity is correctly configured. The important question is whether the deployed role can perform its intended operation under its intended permissions.

Rebuild the custom solution against the target

Sitecore’s solution deployment instructions call for referencing the new components, fixing breaking changes, recompiling, preserving customizations in separate patch files, and handling non-patchable configuration as needed. Use that as the build workstream. Preserve the resulting artifact and its manifest so that the tested release and production release can be compared directly.

Review compilation failures as evidence about dependencies rather than treating all of them as missing-reference problems. Map each failure to a changed API, package relationship, removed component, or custom extension. Record the resolution and the test that exercises it. A successful rebuild is necessary, but it does not show that a custom processor still runs in the right place or that a computed field produces the intended result.

Search the solution and deployment scripts for the extension points identified by the official breaking changes. For search, that includes custom schema helpers and schema-provisioning assumptions. For other areas, build an analogous inventory from the documented changes. Keep the detailed remediation in the dedicated breaking-changes workstream; the production runbook should link to its completion evidence and make unresolved failures a stop condition rather than repeating the entire analysis.

Migrate intent, then inspect the effective result

My configuration preference is to start from the clean 10.5 baseline and reapply understood customizations. For each existing patch, record why it exists, whether the target still requires it, and which environment differences it expresses. Workarounds deserve special attention: a historical workaround can become an unwanted override after the original defect is fixed. If nobody can explain a patch, investigate it before carrying it forward.

Separate repository changes from environment bindings. The same application artifact may need different endpoint names or secrets across environments, but the team should be able to identify which mechanism supplies those differences. Compare the effective configuration in the rehearsal target with the intended result. Do not assume that a patch file present on disk actually changes the node you expected; inspect the resolved behavior through approved diagnostic methods.

Verify publishing targets, scheduled tasks, integration URLs, and outbound credentials before enabling work. These checks overlap with isolation, but the purpose here is different: the target should be both correctly configured and deliberately activated. A replacement endpoint used during rehearsal must not silently carry into production, and a production endpoint must not silently appear in an isolated test environment. Put both comparisons into the environment review.

Make search readiness observable

Complete the documented Solr schema and indexing work using the target’s approved configuration. The broad runbook should capture which indexes exist, which roles use them, how rebuild completion is verified, and which representative queries are expected to pass. Keep the detailed core and schema migration procedure in the dedicated Solr article or a linked project runbook. Avoid hiding an unfinished rebuild behind a healthy application startup message.

Test more than reachability. Choose representative search cases from your application: a known item lookup, language handling, filtering, sorting, and facets where used. Compare intended outcomes rather than merely checking that a request returns a response. If the new release changes documented search semantics, update the acceptance expectations deliberately and have the application owner review the consequence. An unexplained result difference should remain open.

The deployment gate passes when the target baseline is preserved, the exact rebuilt artifact is deployed, environment bindings have been checked, search work is complete, and the application starts without unresolved release-blocking failures. Keep evidence tied to the artifact identifier. If another build is deployed after this point, determine which acceptance checks must be repeated instead of assuming earlier evidence automatically transfers.

5. Validate workflows and rehearse the production decision

Turn business journeys into acceptance records

Define acceptance around the tasks people need to complete. For an editor, that might be signing in, opening a representative page, changing content, using Experience Editor where applicable, submitting workflow, and publishing. For a visitor, it might be opening the resulting page, loading media, searching, and submitting a form. For an operator, it includes observing failures and recovering a service. Select journeys that reflect the actual solution rather than a generic product demo.

For each journey, record a safe test identity, controlled test data, expected outcome, evidence location, and cleanup procedure. Use explicit content identifiers or test routes where possible. A screenshot of an open editor can show that a screen loaded; it does not show that the correct language version was published to the intended target. Pair visual evidence with the application or data outcome the test is meant to establish.

Use the official post-upgrade chapter to build an applicability checklist. It includes maintenance, xDB-related work, reporting, serialization-format migration, Identity, and Solr topics. Read the linked instructions before marking an item required or not applicable. Their appearance in the chapter is not evidence that every operation belongs to a 10.4 source estate.

Make the acceptance matrix easy to inspect

The following matrix is a proposed starting point. Replace its examples with the actual journeys and tests used by your team. Each row needs an owner and a recorded outcome. Distinguish a blocked test from a passed test and an accepted exception from an unnoticed omission. That vocabulary helps the release owner assess evidence without having to infer the state from scattered chat messages.

Include negative and authorization cases. A successful privileged request does not demonstrate that an unauthorized user is rejected. A publishing test that uses only approved default content does not exercise a custom workflow. Ask the security and content owners which boundaries are material for their installation. Convert those answers into safe tests, and avoid generating unnecessary sensitive production data merely to make the test look realistic.

For integrations, trace a test transaction from entry to the downstream effect and back to the application result. Keep the correlation record. Test what the application does when the dependency fails or is unavailable using an approved non-production method. The question is whether the upgraded solution handles the failure according to its contract, not whether every external service can be made perfectly reliable during the upgrade.

Compare performance without inventing a benchmark

Capture a baseline on the source estate and repeat the chosen workload on the target under comparable conditions. Record content selection, cache state, request mix, concurrency, dependency location, and observation method. Separate cold-start behavior from warmed request behavior. This article provides no claimed percentage improvement because no workload from your environment has been measured. The release decision should use your evidence and your service objectives.

Investigate a regression before accepting it as normal upgrade overhead. Ask whether the comparison used equivalent data, whether background work was still running, and whether configuration or dependency changes altered the result. Preserve raw observations alongside the interpretation. A single favorable average can hide a slow critical journey; choose metrics that help the team assess the business paths it has actually agreed to protect.

Verify observability as a functional requirement. Generate a safe known request and confirm that operators can find the expected application and dependency evidence. Confirm who receives an alert and how they identify the release involved. If the new system cannot be diagnosed during a controlled test, the production window will be harder to operate. Monitoring configuration should pass before it is needed to explain a live failure.

Rehearse the decision, including a deliberate abort

Run the procedure from the same starting conditions you intend to use in production. Record actual step durations and operator handoffs. Include the authoring freeze, backup selection, database sequence, deployment, validation, and traffic decision. Where an environment difference prevents a step from being reproduced, document the difference and the substitute evidence. Do not mark an unexercised production-specific action as rehearsed.

Perform a deliberate abort in a controlled environment. Choose a representative failure point, invoke the documented stop action, and verify that the recovery operator can restore the agreed state. The purpose is to exercise the decision and communication path as well as the technical procedure. A plan can be technically sound and still fail if nobody knows who has authority to stop the window.

Before scheduling production, review open defects and accepted exceptions with the accountable owners. Each exception needs impact, rationale, mitigation, expiry or follow-up, and explicit acceptance. “Known issue” should not be used as a substitute for a decision. The rehearsal gate passes only when the release owner can explain what is proven, what remains uncertain, and why the remaining uncertainty is acceptable.

6. Execute cutover, rollback, and operational handover

Run the window from a single decision record

Open the production window by confirming the release artifact, participants, approvals already required by your organization, current dependency health, and the recovery boundary. State the latest safe decision time. Give the release lead one authoritative record for step status and evidence. Separate technical discussion from the status log so that an operator can see the current state without reading an entire conversation.

Apply the agreed authoring and writer controls, verify the intended quiet state, and create or confirm the selected recovery set through the approved procedure. Follow the rehearsed database and deployment sequence. Require reviewers at the steps where a wrong destination would have serious consequences. Verification should use the actual server and database identifiers, not an environment nickname that could refer to multiple resources.

Record start and finish times, results, and exceptions as the work happens. If a step exceeds its locally selected duration limit, call the planned review rather than silently borrowing time from recovery. A delay is not automatically a failure, but it changes the remaining options. The release lead should make that tradeoff explicitly with the owners who are accountable for service availability and data protection.

Move traffic only after the agreed preconditions

Use the routing mechanism and sequence tested for your installation. This article does not prescribe a universal DNS or load-balancer command. The operator should know which change moves traffic, how to observe the destination actually serving a request, and how to return traffic if that becomes necessary. Include certificates, hostname behavior, and application readiness in the acceptance of the public path.

Keep the pre-traffic checks short enough to execute reliably and specific enough to block a bad release. Verify the release identity, critical dependencies, representative content, and the essential business journey selected during planning. Run broader regression during rehearsal and retain its evidence; do not attempt to improvise an entire test program during the maintenance window. Production checks should confirm that the intended release reached the intended environment.

After traffic moves, observe the selected critical journeys and operational signals for the agreed period. Compare against the defined acceptance boundaries. If a failure appears, preserve the request and dependency evidence before changing the system. Ask whether the failure meets a rollback trigger, can be resolved inside the remaining safe window, or needs a business decision. Avoid open-ended repair attempts with no recorded decision point.

Distinguish routing rollback from state recovery

A routing change can be reversed quickly in some architectures, but state recovery is a separate question. The old application needs a compatible and coherent state. Sitecore’s serialization-format changes are one reason to review data compatibility explicitly in the official guidance. Do not assume that pointing old binaries at databases written by the new release is a tested rollback. Use the recovery path demonstrated for your estate.

Before executing recovery, identify which new writes and external effects occurred after the boundary. Apply the documented reconciliation or compensation process with the responsible owners. Preserve failed-release logs and the release record so that root-cause analysis remains possible after service returns. Restoration should not erase the evidence needed to explain why the migration failed or which users were affected.

Validate the recovered service with the same seriousness as the upgraded service. Confirm routing, release identity, dependencies, critical journeys, and monitoring. State clearly whether the outcome is a completed upgrade, a successful recovery to the previous release, or a degraded service requiring incident management. These outcomes imply different follow-up work and should not be collapsed into a generic “deployment completed” message.

Close the window with an operational owner

Hand over the deployed release, configuration references, monitoring locations, outstanding exceptions, and incident contacts. Assign ownership for any deferred background work or rebuilding activity, and state how completion will be verified. Keep the previous recovery set according to the retention decision agreed with the data owners. Retiring it is a separate action that should happen only when the organization accepts the resulting loss of recovery options.

Review the runbook after the window. Replace assumed durations with observed durations, record unexpected steps, and distinguish reusable improvements from environment-specific exceptions. If the upgrade was rolled back, preserve the failed sequence and the cause analysis before preparing another attempt. A second attempt should have a clear explanation of what changed and which rehearsal evidence demonstrates that the original failure has been addressed.

The practical completion criterion is a supported, verified target that an identified team can operate, with a known recovery posture and no hidden ownership gaps. The next concrete action is to populate the database action matrix and recovery record for your actual 10.4 estate, then run the full rehearsal on isolated copies. Only that evidence can turn this proposed runbook into a production-ready procedure for your installation.