The homepage loads. Is the CMS upgrade really finished?
A successful deployment is only one part of a CMS upgrade. Follow the work of a buyer and a content author to understand what meaningful post-upgrade validation should cover.
A CMS upgrade has two first mornings: one for the team deploying it, and another for the people returning to their work. Consider how that second morning could unfold. The homepage loads, the navigation looks familiar, and the deployment appears healthy. Then a content author opens a product resource to make a small correction. Somewhere else, a prospective customer starts a quote request.
Those two ordinary tasks reveal more about the upgrade than the homepage alone. Can the author preview and publish? Does the customer’s form render, validate, and reach the intended destination? Can both people complete the work they came to do?
That difference in perspective reveals a practical distinction: restoring pages is not the same as restoring the business workflows behind them. Recent production Sitefinity upgrade work by GCG included both technical deployment and validation of public and editorial experiences. The lesson is to define completion around the people who depend on the site, then choose checks that provide evidence for those journeys.
Start with the work the website supports
A manufacturer’s website may be a publishing platform, a document library, a lead-generation channel, and a route to a dealer or distributor. Its value is spread across those jobs. A technically successful upgrade can still leave one of them interrupted.
Before the release, identify representative journeys with the people who own them. A buyer might find a product page, download a technical document, and request help. A marketer might edit an existing page, preview it, and publish a correction. An administrator may need to manage content or verify access.
The resulting validation scope should reflect the actual site rather than a generic inventory of CMS features. It should also distinguish critical workflows from lower-priority observations. That makes the release discussion concrete: the team can explain which business paths were exercised, which evidence was collected, and where any uncertainty remains. A long checklist has limited value if no one can connect its items to how the organization works.
Follow content from the editor to the visitor
Public pages and the authoring experience are connected, but they do not fail in identical ways. A page may render correctly while an editor encounters a broken preview, missing control, or publishing problem. Conversely, the backend may look normal while a visitor receives an incomplete component.
A representative editorial journey bridges the two. Open existing content, inspect the editing experience, preview a controlled change, and confirm the expected publishing behavior within the agreed validation scope. Then inspect the public result. Document and media links deserve attention too, especially when technical resources are part of the buyer’s decision.
In the production Sitefinity work informing this article, validation included public pages and documents as well as administration, preview, and publishing. These checks answer different questions. Together they give a more useful picture than repeating the same page-load test across many URLs. The aim is to establish that the content lifecycle still works from its origin to its destination.
A visible form is not proof of a working request
Forms cross several boundaries. The CMS renders the fields, client-side behavior guides the visitor, verification may involve another service, and submission may trigger storage, notifications, or downstream processing. Seeing the first step does not establish the result of the last.
For a release that changes or places a business-critical form at risk, an agreed controlled submission can provide stronger evidence. The team should know what data will be used, who will recognize the test, and which outcome confirms success. That keeps validation useful without creating unexplained requests for business teams.
The recent work included controlled submission testing during an initial upgrade and form rollout. Later maintenance validation included read-only checks of rendering and related workflows. Those are different levels of evidence, and release reporting should preserve the distinction. ‘The form renders’ is a valid observation. ‘A request completed successfully’ requires evidence that the request actually traveled through the relevant path.
Follow the work through the upgrade
Editorial
- Authoring opens
- Preview represents the draft
- Publishing follows the intended path
Public experience
- Pages and navigation
- Published documents
- Lookup experience
Form workflow
- Form renders
- Verification behavior
- Controlled submission and response
- Start with the author
The team must be able to create, preview, and publish useful content. - Follow the visitor
Public pages, documents, and lookup paths deserve their own validation. - Distinguish the test
Read-only inspection and controlled workflow tests answer different questions.
Follow three kinds of work through the upgrade
Read the sketch from the Editorial lane across to Public experience, then Form workflow. Authoring, preview, and publishing cover the people maintaining the site. Pages, documents, and lookup cover the people using it. Form rendering, verification, and a controlled submission reach into a different part of the journey. Notice the separate notes for read-only review and a controlled test. Those checks provide different evidence, even when they appear in the same release review. The lanes make that difference visible and give the team a way to discuss the scope without compressing every observation into one reassuring check mark.
Make the release decision legible
The final review should let a business owner understand what was changed and how the team established readiness. Grouping evidence around journeys helps: public information, content authoring, inquiry capture, and supporting lookup experiences. Any check that could not be completed should remain visible.
Preparation matters as well. A defined deployment sequence, appropriate backups, and a recovery approach support the release, while post-deployment observations show whether the intended experience returned. These are complementary parts of the work, not substitutes for each other.
A useful closing question is, ‘What can our customers and content team do now, and what evidence supports that answer?’ It shifts the conversation from a new version number to the operation of the website. The upgrade is ready to hand back when the organization can understand the result, recognize any limits, and resume the workflows that make the platform valuable.
Images are original conceptual illustrations, not photographs of a client project.