Adopting PRIZM

Adopting PRIZM 4 isn't a one-off migration. It's a way of evolving your product alongside PRIZM — bringing the system in where new work happens, and letting the rest follow over time. This page is about doing that without putting everything else on hold.

You don't have to rebuild everything

There's a common worry that taking on a new design system means a full redesign: freeze the roadmap, rework every screen, ship the lot in one go. For a small product that can be reasonable. For a large one it rarely is, and for a programme that runs for years it's close to unworkable.

Your teams keep shipping features the whole time, so it's not that work stops. The problem is the look and feel: it sits frozen for the years a full redesign takes, while PRIZM keeps evolving. The longer it drags, the more dated the product looks — and the version you finally ship is already a step behind.

So we don't suggest doing it that way. There's a better route, and it's the one most large software actually takes.

Bring it in gradually

Rather than one cutover, bring PRIZM 4 in where new work is already happening, and let the older parts follow when their turn comes. A few habits keep this working in practice.

New work starts on PRIZM 4

Every new module or application is built on PRIZM 4, without debating it case by case. This is the easiest place to adopt, too: there's no existing code to unpick, so you're building on the current system from the start.

Refresh when you're already in there

Your older modules don't need a migration plan of their own. Most of them will be reworked at some point anyway — a feature gets rebuilt, part of the product gets an overhaul. When that happens, move the module to PRIZM 4 as part of the same work, rather than rebuilding it again in a version we no longer support.

The risk with this is that “we'll do it next time we're in there” turns into never. On a long programme, keep a simple list of which modules are on which version of PRIZM, so someone can see what's left and the migration doesn't quietly stall.

Split old and new by module

This is the part worth getting right. It's fine for different modules to look different — people are used to the newer parts of a product looking newer than the older ones. The problem is when the difference shows up inside a single task: a form where the top half looks new and the bottom half old, or a workflow that changes style partway through.

So keep the boundary between modules, where people are already moving from one part of the product to another, and not inside a single piece of work. That's where consistency actually matters. Across a whole product built up over ten years, some difference between the parts is expected, and users won't hold it against you.

Start with the shell

If there's one place to start, it's the shared frame around everything — the top bar, the navigation, the shell your modules sit inside. Moving that to PRIZM 4 early makes the biggest visible difference: the product as a whole starts to look current, even while most of the module content is still on the old system. In C3, the App Shell template is built for precisely this.

How it plays out

Picture a dispatch platform that's run for six years: a live operations console, a shift-planning module, a reporting area, and an admin back-end. You don't rebuild all four. The incident-review module you're starting this quarter is built on PRIZM 4. The operations console — the screen everyone watches all day — gets the PRIZM 4 shell now, so the product feels current. Shift-planning is due a rework next year and moves across then. Reporting and admin stay as they are until they're due for a refresh. A year in, a good part of the product is on PRIZM 4, and no roadmap was ever frozen to get there.

Won't it look inconsistent?

Everyone asks this, so let's answer it straight. Yes — for a while, parts of your product will look as though they were built at different times, because they were. That isn't a new problem, and it certainly isn't yours alone.

It's a recognised way of working, and it has a name: coexistence — an old system and a new one running side by side while the new one gradually takes over. The biggest software in the world runs this way. Salesforce ran Classic and Lightning side by side for years and let each org move across when it was ready, rather than flipping everyone at once. SAP's Fiori has sat next to older screens for over a decade; its Launchpad is really just a modern frame around applications of wildly different ages — the same “start with the shell” idea, at enormous scale. Even Windows has shipped the old Control Panel beside its newer Settings for well over a decade.

None of them waited for a clean-slate moment to modernise, because in software that's actually in use there is no clean-slate moment. They did it continuously, in the open, and it worked. The all-at-once alternative isn't more consistent. It reaches the same place with more risk, carried for longer.

Where to start

The first step is a small one. Take the next new module on your plan and build it on PRIZM 4. Move the shared shell over early so the surroundings feel current. Keep a short note of what's on which version. After that, new work and the usual reworking of old modules will carry the rest across over time.