K
Katie Austin
Guest
If your team is contemplating a Sitefinity CMS upgrade, use this matrix to assess what you need to shore up before making the move or if your site is ready.
The version of Progress Sitefinity CMS you’re running is only one factor in determining the scope of an upgrade.
Your frontend rendering technology, custom modules, third-party integrations, search configuration, deployment model and test coverage can all affect the work involved. Understanding those dependencies before an upgrade helps teams identify where additional planning, validation or modernization may be required.
That’s why upgrade readiness starts with a clear picture of the environment you have today.
The Sitefinity Upgrade Readiness Matrix provides a practical way to assess seven areas of your implementation and identify where upgrade risk and effort are likely to concentrate.
Use the matrix to document your current Sitefinity implementation, identify dependencies and assign separate risk and effort ratings to each area.
Once the inventory is complete, rate each area separately:
Keeping the two separate gives teams a clearer picture of where upgrade work and further investigation are likely to concentrate.
Start by confirming the exact Sitefinity version and patch level running in each environment. Then compare that starting point with your target version and check its status under the Sitefinity lifecycle policy.
Depending on your starting point, you may need to account for intermediate upgrades, prerequisites or version-specific changes before reaching the target release. Review the relevant upgrade documentation and release notes to identify anything that could affect your implementation.
Capture:
Readiness output: A confirmed upgrade path, with version-related dependencies or blockers identified before work begins.
Frontend rendering technology can significantly affect upgrade scope, so identify what is in use across your pages, templates, widgets and custom frontend components.
Pay particular attention to Web Forms. Progress discontinued support for Web Forms frontend capabilities in Sitefinity 14.1, so implementations that still depend on them need to account for technology migration.
For MVC, identify existing pages, templates, widgets and customizations, and determine whether modernization to ASP.NET Core or Next.js should be part of the upgrade plan.
For ASP.NET Core, Next.js or mixed implementations, document the components and dependencies that need to be validated against the target Sitefinity version.
Capture:
Readiness output: A renderer inventory showing what can remain, what needs validation and where technology migration needs to be factored into the upgrade.
Custom functionality needs its own place in the readiness assessment because its dependencies may need to be validated against the target version.
Inventory custom modules, widgets, APIs, libraries and configuration changes, and document what each customization depends on. Pay particular attention to dependencies on Sitefinity APIs or functionality that has changed or been deprecated in the target version.
Ownership and documentation matter too. Teams need to know what a customization does, where it is used and how it can be tested after the upgrade.
Capture:
Readiness output: A customization inventory showing what needs to be retained, validated, refactored or replaced as part of the upgrade.
Integrations can introduce dependencies that need to be validated as part of an upgrade. Start by identifying every external system connected to your Sitefinity instance and how that connection works.
This can include CRM, marketing automation, identity, analytics, commerce and other business systems connected through APIs, connectors, webhooks or custom integration code.
For each integration, consider both its technical complexity and business importance. A relatively simple integration may still require careful validation if it supports a critical customer journey or business process.
Capture:
Readiness output: An integration map showing key dependencies, ownership and the validation required before the upgraded environment goes live.
Search configuration should be part of the upgrade inventory, particularly where an implementation uses multiple indexes, custom configuration or external search services.
Document the search indexes in use, what content they cover and any providers, custom fields or other dependencies involved. This gives teams a clear picture of what needs to be recreated, reindexed or validated as part of the upgrade process.
Capture:
Readiness output: A search inventory and plan for validating indexes, configuration and expected search behavior after the upgrade.
How Sitefinity CMS is hosted and deployed can affect the upgrade process, so document the current deployment model before planning how the upgraded implementation will move through environments.
Map the environments involved, how code and configuration are deployed between them and any infrastructure or environment-specific dependencies. Pay particular attention to manual steps or configuration differences that could make the upgrade harder to reproduce consistently.
Capture:
Readiness output: A documented deployment path, including dependencies and manual steps that need to be addressed.
Upgrade readiness isn’t just about whether the implementation can be upgraded. Teams also need a reliable way to verify that critical functionality still works as expected afterward.
Review the automated and manual test coverage you have today, focusing on the areas identified elsewhere in the readiness assessment. This should include critical content and publishing workflows, customizations, integrations, search and high-value customer journeys.
Where coverage is limited, identify the regression and acceptance tests that need to be established before the upgrade begins. Sitefinity CMS also provides a test framework for validating content types that can support content validation as part of the process.
Capture:
Readiness output: A validation plan showing what will be tested, where coverage needs strengthening and how upgrade readiness will be determined.
Once you’ve assessed the seven areas, assign each one separate risk and effort ratings. A simple Low, Medium or High scale is enough to identify where additional investigation or planning is needed.
Keep risk and effort separate, as a dependency can be high-risk without requiring significant effort to validate, while a well-understood migration may require substantial work. Use the evidence from your assessment to rate each area and identify where further investigation or planning is needed.
A Sitefinity upgrade starts with the version you’re running, but the full scope depends on much more. Rendering technologies, customizations, integrations, search, deployment and test coverage can all influence the risk and effort involved.
Using the readiness matrix gives teams a clearer picture of those dependencies before timelines and resources are committed. It also helps surface where additional investigation, migration or validation may be needed.
The result is a more informed upgrade plan based on the implementation you actually have, not assumptions about what the upgrade should involve.
Ready to assess your Sitefinity implementation?
Visit the Sitefinity Upgrade Center for upgrade guidance, resources and next steps.
Continue reading...
The version of Progress Sitefinity CMS you’re running is only one factor in determining the scope of an upgrade.
Your frontend rendering technology, custom modules, third-party integrations, search configuration, deployment model and test coverage can all affect the work involved. Understanding those dependencies before an upgrade helps teams identify where additional planning, validation or modernization may be required.
That’s why upgrade readiness starts with a clear picture of the environment you have today.
The Sitefinity Upgrade Readiness Matrix provides a practical way to assess seven areas of your implementation and identify where upgrade risk and effort are likely to concentrate.
Start with the Sitefinity Upgrade Readiness Matrix
Use the matrix to document your current Sitefinity implementation, identify dependencies and assign separate risk and effort ratings to each area.
| Assessment area | What to assess | Potential risk or effort indicators | Output |
|---|---|---|---|
| Current version | Version, patch level, lifecycle status and target version | Older or retired versions, intermediate upgrade steps, deprecated functionality | Confirmed upgrade path |
| Frontend rendering technology | Web Forms, MVC, ASP.NET Core and Next.js usage | Legacy or mixed technologies, custom components, modernization requirements | Renderer inventory and migration requirements |
| Customizations | Custom modules, widgets, APIs, libraries and configuration | Extensive custom code, undocumented dependencies, changed or deprecated functionality | Customization inventory |
| Third-party integrations | Connected systems, APIs, connectors, webhooks and data flows | Critical integrations, custom code, unclear dependencies or ownership | Integration map and validation requirements |
| Search indexes | Indexes, providers, indexed content and configuration | Customized indexes, external dependencies, reindexing requirements | Search validation plan |
| Deployment model | Hosting, environments and deployment process | Environment-specific configuration, manual steps, infrastructure dependencies | Upgrade deployment path |
| Test coverage | Automated, integration, regression and user acceptance testing | Limited coverage or gaps around critical workflows | Upgrade validation plan |
Once the inventory is complete, rate each area separately:
- Risk: How likely is it to introduce compatibility issues, blockers or unexpected behavior?
- Effort: How much investigation, development, migration or testing is likely to be required?
Keeping the two separate gives teams a clearer picture of where upgrade work and further investigation are likely to concentrate.
1. Establish Your Current Version and Upgrade Path
Start by confirming the exact Sitefinity version and patch level running in each environment. Then compare that starting point with your target version and check its status under the Sitefinity lifecycle policy.
Depending on your starting point, you may need to account for intermediate upgrades, prerequisites or version-specific changes before reaching the target release. Review the relevant upgrade documentation and release notes to identify anything that could affect your implementation.
Capture:
- Current Sitefinity version and patch level
- Lifecycle status
- Target version
- Required upgrade steps or intermediate versions
- Relevant breaking changes, deprecated functionality and prerequisites
Readiness output: A confirmed upgrade path, with version-related dependencies or blockers identified before work begins.
2. Identify Your Frontend Rendering Technologies
Frontend rendering technology can significantly affect upgrade scope, so identify what is in use across your pages, templates, widgets and custom frontend components.
Pay particular attention to Web Forms. Progress discontinued support for Web Forms frontend capabilities in Sitefinity 14.1, so implementations that still depend on them need to account for technology migration.
For MVC, identify existing pages, templates, widgets and customizations, and determine whether modernization to ASP.NET Core or Next.js should be part of the upgrade plan.
For ASP.NET Core, Next.js or mixed implementations, document the components and dependencies that need to be validated against the target Sitefinity version.
Capture:
- Web Forms and MVC pages, templates and widgets
- ASP.NET Core and Next.js implementations
- Mixed rendering technologies
- Custom frontend components and dependencies
- Migration or validation requirements
Readiness output: A renderer inventory showing what can remain, what needs validation and where technology migration needs to be factored into the upgrade.
3. Inventory Custom Modules and Customizations
Custom functionality needs its own place in the readiness assessment because its dependencies may need to be validated against the target version.
Inventory custom modules, widgets, APIs, libraries and configuration changes, and document what each customization depends on. Pay particular attention to dependencies on Sitefinity APIs or functionality that has changed or been deprecated in the target version.
Ownership and documentation matter too. Teams need to know what a customization does, where it is used and how it can be tested after the upgrade.
Capture:
- Custom modules
- Custom widgets and components
- Custom APIs and services
- Third-party libraries and dependencies
- Configuration changes
- Dependencies on changed or deprecated functionality
- Technical ownership and documentation
Readiness output: A customization inventory showing what needs to be retained, validated, refactored or replaced as part of the upgrade.
4. Map Third-Party Integrations
Integrations can introduce dependencies that need to be validated as part of an upgrade. Start by identifying every external system connected to your Sitefinity instance and how that connection works.
This can include CRM, marketing automation, identity, analytics, commerce and other business systems connected through APIs, connectors, webhooks or custom integration code.
For each integration, consider both its technical complexity and business importance. A relatively simple integration may still require careful validation if it supports a critical customer journey or business process.
Capture:
- Connected system and business purpose
- Integration method
- Authentication method
- Data exchanged
- Custom code or middleware
- Business and technical owners
- How the integration will be tested after the upgrade
Readiness output: An integration map showing key dependencies, ownership and the validation required before the upgraded environment goes live.
5. Assess Search Indexes and Dependencies
Search configuration should be part of the upgrade inventory, particularly where an implementation uses multiple indexes, custom configuration or external search services.
Document the search indexes in use, what content they cover and any providers, custom fields or other dependencies involved. This gives teams a clear picture of what needs to be recreated, reindexed or validated as part of the upgrade process.
Capture:
- Existing search indexes
- Content included in each index
- Search providers or services
- Custom fields and configuration
- External search dependencies
- Reindexing and post-upgrade validation requirements
Readiness output: A search inventory and plan for validating indexes, configuration and expected search behavior after the upgrade.
6. Document the Deployment Model
How Sitefinity CMS is hosted and deployed can affect the upgrade process, so document the current deployment model before planning how the upgraded implementation will move through environments.
Map the environments involved, how code and configuration are deployed between them and any infrastructure or environment-specific dependencies. Pay particular attention to manual steps or configuration differences that could make the upgrade harder to reproduce consistently.
Capture:
- Hosting and deployment model
- Development, test, staging and production environments
- Deployment process
- Environment-specific configuration
- Infrastructure dependencies
- Manual deployment steps
- Rollback approach
- Owners and approvals
Readiness output: A documented deployment path, including dependencies and manual steps that need to be addressed.
7. Assess Your Test Coverage
Upgrade readiness isn’t just about whether the implementation can be upgraded. Teams also need a reliable way to verify that critical functionality still works as expected afterward.
Review the automated and manual test coverage you have today, focusing on the areas identified elsewhere in the readiness assessment. This should include critical content and publishing workflows, customizations, integrations, search and high-value customer journeys.
Where coverage is limited, identify the regression and acceptance tests that need to be established before the upgrade begins. Sitefinity CMS also provides a test framework for validating content types that can support content validation as part of the process.
Capture:
- Automated test coverage
- Content type validation
- Integration tests
- Critical editorial and publishing workflows
- High-value customer journeys
- Regression test cases
- User acceptance testing
- Any significant gaps in existing coverage
Readiness output: A validation plan showing what will be tested, where coverage needs strengthening and how upgrade readiness will be determined.
Turn the Assessment into Risk and Effort
Once you’ve assessed the seven areas, assign each one separate risk and effort ratings. A simple Low, Medium or High scale is enough to identify where additional investigation or planning is needed.
| Rating | Risk | Effort |
|---|---|---|
| Low | Dependencies are understood, with no significant known compatibility concerns | Primarily routine upgrade, configuration and validation work |
| Medium | Some dependencies or compatibility questions still need to be resolved | Targeted development, migration or additional testing is likely |
| High | Known technology changes, critical dependencies or significant unknowns could affect the upgrade | Substantial migration, redevelopment or validation may be required |
Keep risk and effort separate, as a dependency can be high-risk without requiring significant effort to validate, while a well-understood migration may require substantial work. Use the evidence from your assessment to rate each area and identify where further investigation or planning is needed.
Assess Before You Schedule
A Sitefinity upgrade starts with the version you’re running, but the full scope depends on much more. Rendering technologies, customizations, integrations, search, deployment and test coverage can all influence the risk and effort involved.
Using the readiness matrix gives teams a clearer picture of those dependencies before timelines and resources are committed. It also helps surface where additional investigation, migration or validation may be needed.
The result is a more informed upgrade plan based on the implementation you actually have, not assumptions about what the upgrade should involve.
Ready to assess your Sitefinity implementation?
Visit the Sitefinity Upgrade Center for upgrade guidance, resources and next steps.
Continue reading...