What information is needed before estimating an upgrade?
Start with repository and environment access, the current CMS and runtime versions, package inventory and the business workflows that must be preserved. These establish the scope; an estimate should also state assumptions and unresolved compatibility questions.
- CMS, runtime, package and hosting versions, including custom extensions
- Content models, media storage, data volumes and external system dependencies
- Build and deployment steps, environment configuration and access owners
- Editor and visitor acceptance scenarios, release constraints and recovery requirements
Inventory the application and its dependencies
Record the current CMS and runtime versions, installed packages, custom back-office functionality and integrations. Identify who owns each dependency and whether a target-version-compatible release exists. An inventory turns an uncertain upgrade into a set of decisions to investigate.
Map content and business workflows
List the editor journeys and public features that must continue working. Include publishing, media, forms, search and connected systems where present. Agree what data is needed for realistic testing and how that data can be used safely outside production.
Separate unknowns from implementation
An unsupported package or undocumented integration may need a short investigation before a reliable estimate is possible. Record assumptions, dependencies and exclusions alongside the proposed scope. Do not treat a successful local build as proof of a completed migration.
How do you choose a path for an unsupported package?
Compare the behaviour the organisation needs with the available options. The following is an illustrative assessment framework, not a description of a particular client implementation.
| Option | When to consider it | Evidence to collect |
|---|---|---|
| Upgrade | A maintained release supports the target platform and required behaviour. | Compatibility documentation and tests against the existing workflows. |
| Replace | An alternative meets the requirement but changes data or configuration. | A feature comparison, migration rehearsal and reconciliation checks. |
| Build | The requirement is specific and the team can own custom functionality. | A scoped prototype, failure scenarios and an agreed maintenance owner. |
| Retire | The functionality is no longer needed. | Business approval and checks for stored data and dependent workflows. |
What should a migration rehearsal verify?
Rehearse the proposed steps on a protected, representative copy of the platform. Capture results and exceptions so the team can repeat the process and distinguish a successful deployment from a correctly functioning site.
- Content and media are present and key records reconcile with the source
- Editors can sign in, edit, preview and publish the agreed content types
- Public routes, redirects, forms, search and integrations behave as expected where present
- Migration errors are recorded and recovery steps are feasible for application and data changes
Include release readiness in the estimate
Plan migration rehearsals, acceptance testing, environment configuration and handover. Agree the release window and recovery strategy with the team operating the site. The assessment should end with a proposed path, visible uncertainties and a clear next decision.
What should the assessment produce?
A useful assessment gives the delivery team a reviewable basis for a decision. Its depth depends on the platform and the access available; it should identify work that still needs investigation rather than disguise uncertainty as a fixed commitment.
- A compatibility register with upgrade, replacement and investigation decisions
- A proposed scope with assumptions, exclusions and dependencies
- An estimate that separates known implementation from unresolved investigations
- Acceptance criteria, migration sequencing and a release and recovery outline
- Named owners for outstanding decisions and the next review point
What must be established before release approval?
Agree who accepts the functional test results, who owns the migration and who can approve or halt the release. Record unresolved defects and their impact. Check environment configuration and recovery options with the operating team. A green pipeline is one input to that decision; it does not establish that every business workflow has passed.
Reference documentation
Check the guidance for your exact source and target versions before implementation.
Continue exploring
Discuss your platform
Share your current platform, the change you need and your delivery constraints. Scope and engagement can be discussed around your team.
Discuss an Umbraco Project