Umbraco 8 to 13 Upgrade: How NYC Votes Stayed Available to 5.5M Voters

Phases upgraded NYC Votes from Umbraco 8 to Umbraco 13 while the civic platform continued serving more than 5.5 million New York City voters. The platform supports 14 languages, external data services and Salesforce workflows. The upgrade brought the site onto a newer Umbraco and .NET generation without interrupting public access.

For an organisation planning an Umbraco upgrade, that last part is often more important than the version number.

An established website may contain years of content, custom development, forms, APIs, search, analytics, publishing workflows and third-party systems. Changing the CMS underneath them is only one part of the job.

The harder question is whether everything the organisation depends on still works when the new platform goes live.

That was part of the challenge with NYC Votes.

The upgrade at a glance

This was more than a CMS version update

NYC Votes provides election information and voter services across New York City.

Information changes throughout each election cycle. Candidate and district data can change. Traffic can increase around key voting periods. Editors need to publish across several languages.

The platform also depends on systems outside Umbraco.

Candidate and district information comes from external data sources. Location services support address-based journeys. Forms have been integrated with Salesforce so submitted information can flow into CRM workflows.

So the upgrade could not be considered complete simply because Umbraco 13 started successfully.

The public site still had to work.

The data exchanges still had to work.

Editors still needed to publish.

Forms still needed to reach the correct systems.

And future releases still had to fit around an active civic platform.

This is an important distinction for any organisation planning an enterprise Umbraco upgrade.

The CMS may be one application. The website around it rarely is.

Why an Umbraco 8 upgrade needs careful planning

Umbraco 8 belongs to an older generation of the platform.

The versions that followed introduced a major change in the underlying Microsoft framework, which means older Umbraco implementations cannot always be treated like a routine version update.

Custom code, packages, templates, integrations and backoffice functionality all need to be understood before the migration path can be decided.

That is why two organisations running the same Umbraco version can face very different upgrade projects.

One website may use mostly standard CMS features.

Another may contain years of bespoke development, several business systems and custom publishing tools.

The starting version tells you where the project begins. It does not tell you how much sits underneath it.

Understanding the existing platform first

With NYC Votes, Umbraco was part of a wider digital service.

That meant understanding more than content pages.

The platform included multilingual publishing, forms, CRM workflows, external election data, location services, infrastructure and an established release process.

That same principle applies to an organisation assessing an older Umbraco implementation today.

Before setting a delivery date or budget, the existing estate needs to be understood well enough to answer questions about packages, custom code, APIs, forms, search, authentication, content models, hosting and deployment.

This is where many upgrade estimates either become credible or fall apart.

A site with 20,000 content pages can sometimes be easier to migrate than a much smaller site containing several unsupported packages and bespoke backoffice extensions.

Page count alone tells very little.

Keeping the public service available

During the NYC Votes upgrade from Umbraco 8 to 13, public access continued.

The platform uses separate development, QA, UAT and production environments. Changes are version controlled, and CI/CD pipelines support releases.

That provided a route for the new implementation to be built and checked away from the public website.

For a public body or enterprise team, this changes the upgrade conversation.

Instead of asking:

How quickly can we install the next Umbraco version?

A better question is:

How do we reach the new platform while keeping the services around the current one working?

That question brings deployment, rollback, testing, integrations and business continuity into the plan early.

The integrations mattered as much as Umbraco

A CMS upgrade can appear successful until an external dependency stops behaving as expected.

NYC Votes works with systems outside Umbraco, including Salesforce, election data sources and location services.

Those services had to continue functioning after the CMS changed.

For another organisation, the dependencies may be different: ERP, CRM, identity providers, search services, payment systems, product data, membership systems, document platforms or bespoke APIs.

This is one reason Phases would not estimate an enterprise Umbraco upgrade from a version number alone.

We first need to understand what enters the CMS, what leaves it and which processes rely on those exchanges.

That information influences the architecture, testing effort and release plan.

Accessibility also had to survive the change

NYC Votes serves a broad public audience.

The platform now supports 14 languages and has achieved a 100% WCAG 2.2 accessibility audit score. The published Umbraco case also documents work around screen-reader compatibility, keyboard use, semantic structure and accessible forms.

A CMS upgrade does not automatically preserve those outcomes.

Templates, interactive components, forms and custom functionality still need to be checked after the technical changes are complete.

The same applies to search behaviour, redirects, analytics, permissions and performance.

A successful upgrade should preserve the parts of the existing service that already work while improving the technical base underneath them.

What the Umbraco 8 to 13 upgrade achieved

NYC Votes was brought from Umbraco 8 onto Umbraco 13 while public access continued.

That gave the platform a newer Umbraco and .NET base from which subsequent development could continue. Phases has continued releasing platform improvements around election cycles using version-controlled deployments and CI/CD.

The important lesson today is not that another organisation should now adopt Umbraco 13.

The support lifecycle has advanced again.

Umbraco 13 reaches End of Life on 14 December 2026. After that date, standard security patches and updates from Umbraco HQ end. Umbraco currently recommends upgrading or rebuilding on Umbraco 17 LTS or above.

So the NYC Votes case demonstrates something broader than a particular destination version.

It shows how an established Umbraco platform can cross a major technical boundary while preserving the public service, integrations and operating process around it.

Still on Umbraco 13?

For teams already running Umbraco 13, the question is now different.

Umbraco 13 is in its final security phase and reaches EOL on 14 December 2026. Umbraco 17 is the current LTS version and is scheduled to remain supported until 27 November 2028.

For some implementations, 13 to 17 may be fairly contained.

For others, custom backoffice extensions, packages, integrations and application code can increase the work considerably.

If your team still cannot confidently answer what needs replacing, what needs rebuilding, what needs testing and how production will be changed, the first useful step is to inspect the existing implementation.

Running Umbraco 13?

Find out what your path to Umbraco 17 involves before the December 2026 EOL date.

Assess our Umbraco setup