NYC Votes: An Umbraco 8 to 13 Upgrade Case Study

The NYC Votes Umbraco 8 to 13 upgrade combined the migration of hundreds of legacy content components with updates to custom application code, search indexing and Salesforce integration.

For a public website serving New York City voters, the work had to preserve the content and functionality people already depended on. The existing website also needed to remain available while the upgraded implementation was prepared.

Phases used uSyncMigrations to help transform Grid content into Block Grid and Nested Content into Block List. The wider application was reviewed and adapted for the newer Umbraco and .NET architecture, with development, QA, UAT and production environments supporting delivery on Microsoft Azure.

This case study explains the migration scope, the purpose of the content transformations and the application dependencies that required separate attention. It also distinguishes the completed upgrade from the wider NYC Votes platform achievements and today’s version-planning decisions.

The upgrade at a glance

Umbraco’s NYC Votes profile also reports a 100% WCAG 2.2 accessibility audit score for the wider platform. The audience, language and accessibility figures describe the broader service; the upgrade-specific work is detailed below.

Read our broader NYC Votes case study for the platform’s ongoing development and multilingual work.

Why NYC Votes needed an Umbraco upgrade

The project addressed security patch requirements, performance and the maintainability of an established codebase.

NYC Votes had structured content, custom functionality and external dependencies built around Umbraco 8. The upgrade therefore needed to account for the application surrounding the CMS as well as its stored content.

Umbraco 8 used ASP.NET MVC on .NET Framework. Umbraco 13 uses ASP.NET Core on .NET 8. Crossing that framework boundary required application development alongside content migration.

For NYC Votes, three areas formed the core scope:

• Content transformation: migrating legacy Grid and Nested Content into the selected Block editors.

• Application redevelopment: reviewing and updating custom code for the newer architecture.

• Service dependencies: maintaining custom indexing and integration behaviour.

These activities needed to be done together to produce a working website. An imported content item would still need compatible rendering code, and a working page would still depend on its search and external services.

Grid to Block Grid and Nested Content to Block List migration

NYC Votes used hundreds of Grid and Nested Content components. They held structured content that needed to remain available to the public and be maintainable by the editorial team.

The project included two transformations:

Phases used uSyncMigrations as part of the content migration. Jumoo’s tooling supports these transformations, providing a way to convert legacy content structures for the destination editors.

The work involved more than transferring text. Content components can include field values, configuration, ordering and references used by the website. The destination content model and the code reading it need to agree on how those values are stored and used.

A Grid to Block Grid migration therefore needs to be considered alongside the updated rendering implementation. The same applies to Nested Content to Block List migration: converting the stored structure is one part of delivering an editable component that renders as intended.

For NYC Votes, the application work accompanied these transformations. uSyncMigrations supported the content conversion while custom functionality was reviewed and adapted separately.

Converting Grid and Nested Content was part of this project’s modernisation scope. Both legacy editors remained available in Umbraco 13 and were removed in Umbraco 14. The conversion should therefore be understood as a project decision, rather than a universal requirement simply to reach version 13.

For another site, the appropriate transformation would depend on its existing content structures, editorial needs and final destination version.

Rebuilding the application around modern .NET

The Umbraco 8 to 13 upgrade also required attention to the code using the migrated content.

Existing custom code was reviewed and, where necessary, refactored or rebuilt for the newer Umbraco and .NET architecture. Content migration tooling did not perform that application redevelopment.

Umbraco’s migration documentation distinguishes preserving content from reimplementing templates and custom code. This distinction is important when estimating an established website: the content volume and the amount of custom functionality describe different parts of the work.

On NYC Votes, the upgraded application needed to use the destination content model while retaining the functionality expected from the service. The updated code, rendering and migrated components therefore had to be compatible with one another.

A comparable assessment should identify which features use standard CMS functionality, which rely on packages and which depend on bespoke code. Package availability and the extent of application customisation affect the redevelopment required.

The NYC Votes project demonstrates this through its combined scope: legacy content conversion, custom application changes, custom indexing and Salesforce integration. Each area contributed to the completed implementation.

Our Umbraco development services cover custom functionality and integrations alongside CMS implementation and ongoing development.

Updating custom indexing for the upgraded website

NYC Votes included custom indexing, which was reviewed, updated and validated during the migration.

Indexing needs attention because stored content and searchable content serve different purposes. A page may contain the intended information while its index omits a value or the search implementation reads a field differently.

Changes to content structures can also affect the code extracting values for an index. When Grid or Nested Content is converted into blocks, the indexing implementation needs to remain compatible with the resulting content model.

For another organisation assessing similar work, useful acceptance questions include:

• Does the updated index include the intended content and fields?

• Do search queries and filters return the expected results?

• Do publishing changes become available through search as intended?

These questions describe how to assess a comparable implementation. The recorded NYC Votes delivery included updating and validating its custom indexing.

Including search within the application scope accounts for functionality that a review of page templates alone would miss.

Updating Salesforce integration and external services

NYC Votes uses services outside Umbraco. Forms integrate with Salesforce, while election information and location-based experiences rely on external systems.

The Salesforce implementation required updates and compatibility validation as part of the upgrade. The website’s interactions with the other services also formed part of the wider implementation being maintained.

A form integration illustrates why this work matters. A form can display correctly and accept input while a later stage of the process fails to deliver the expected information to the receiving system. End-to-end behaviour therefore deserves attention alongside the visible page.

The external system itself may remain unchanged while the website’s application code, configuration or handling of responses needs to be adapted.

For NYC Votes, Salesforce integration was included within the upgrade scope. This was compatibility work on the existing implementation; the wider platform’s earlier transition from NationBuilder to Salesforce is a separate part of its development history.

For another Umbraco website, the equivalent dependencies might include a CRM, identity provider, membership service, product database or bespoke API. The upgrade assessment should establish what information passes between systems and which user journeys rely on those exchanges.

Keeping NYC Votes available during the upgrade work

The existing NYC Votes website remained available while the upgraded implementation was prepared.

Delivery used separate development, QA, UAT and production environments on Microsoft Azure. Changes were managed through version control and CI/CD, allowing development and validation to take place away from the live public service.

This separation mattered for an active platform providing election information and other voter services. The existing application continued serving the public while the upgraded application was prepared for release.

Maintaining public access during the project is the documented continuity outcome. A final production cutover is a distinct event whose deployment window depends on the implementation and hosting setup.

For teams assessing a comparable project, the delivery plan should explain how the existing service will operate during development, how content changes will be handled and how the upgraded application will reach production.

Those arrangements belong in the project scope alongside content migration and application redevelopment. The migration tool alone does not define how an operating website will be upgraded and released.

What the NYC Votes upgrade delivered

The NYC Votes Umbraco 8 to 13 upgrade updated the CMS, legacy content structures and custom application functionality while preserving the wider content structure and maintaining public access during the work.

The development team also reported improvements in performance, security and code maintainability following the upgrade.

The resulting implementation retained the content and functionality needed by the service on an updated technical base. The wider platform’s audience, language provision and accessibility achievements provide context for that work and are described in the broader project account.

What another public-sector team can learn from this project

The scope of this public-sector Umbraco migration extended across content, application code, search, external services and delivery environments.

That combination is useful when assessing an established website with similar dependencies. The starting and destination versions identify the transition, while the content model and surrounding application determine much of the implementation work.

NYC Votes also shows why a content migration estimate should explain the application work around it. Converting a legacy editor, adapting its rendering code and maintaining the services that use its data are related activities with different requirements.

For a team commissioning an upgrade, the useful question is how those activities fit together in the proposed scope. The assessment should identify what will be migrated, what will be redeveloped and what must be validated before release.

Choosing an upgrade destination today

This Umbraco 8 to 13 upgrade case study records a completed project. A new upgrade should assess its destination against the current support lifecycle and the requirements of the existing implementation.

Umbraco 13 reaches End of Life on 14 December 2026 under Umbraco HQ’s standard lifecycle. Umbraco 17 is the current LTS release, with a published End-of-Life date of 27 November 2028.

Package compatibility, custom functionality, content migration and the support period needed after launch should inform the destination decision. A version used as an intermediate migration stage may serve a different purpose from the final production version.

For the wider route from an older installation, read our Umbraco upgrade planning article. If your website is already on version 13, our Umbraco 13 to 17 upgrade article covers the architectural considerations.

What would we assess on another Umbraco upgrade?

A useful assessment should account for the existing build and the service it needs to continue providing.

The NYC Votes project highlights the importance of reviewing:

• Current Umbraco and .NET versions.

• Installed packages and supported replacements.

• Grid, Nested Content and custom property editors.

• Content volume, structure and language provision.

• Templates, bespoke code and backoffice extensions.

• Search indexes and filtering behaviour.

• Forms, CRM flows, APIs and external services.

• Authentication, permissions and editor workflows.

• Hosting, deployment and production configuration.

• Test coverage and accessibility requirements.

• Release, recovery and rollback arrangements.

The output should distinguish content migration from application redevelopment, identify dependencies affecting the route and explain the validation required before release.

That gives the organisation a clearer basis for agreeing scope, responsibilities, budget and delivery timing.

Discuss your Umbraco upgrade requirements

If your Umbraco website includes legacy content editors, custom .NET functionality, search or third-party integrations, include those dependencies in the upgrade assessment.

Phases can review the implementation and discuss the content migration, redevelopment and validation needed for a supported destination.

Explore our Umbraco upgrade services to discuss your current version, content structures and application dependencies with a senior Umbraco consultant.

Assess our Umbraco setup