Moving client sites from Statamic 5 to 6

When Statamic 5 support ends

Statamic's release schedule and support policy gives every major version a fixed lifespan. For Statamic 5, bug fixes ended in March 2026. Security fixes continue until December 2026; after that, a Statamic 5 site is on its own.

That leaves about seven months, which is plenty for a single site. With ten or twenty client sites on Statamic 5, it gets tight faster than it looks. Each upgrade has to fit between other projects and needs its own round of testing, and some clients will want to see the result before it goes live.

For some sites, a second deadline has already passed. Statamic 5 runs on Laravel 10, 11, or 12, but Laravel 10 lost security support in February 2025, and Laravel 11 in March 2026. A Statamic 5 site on either of them is already running a framework without security fixes, regardless of what Statamic does.

What the five minutes don't include

The upgrade guide says that for most sites already on Laravel 12 or higher, the upgrade will take less than five minutes. That's the Composer run, and it's probably true. Statamic even handles some changes during the update, such as splitting global sets into their new file structure. The guide marks three areas as high impact, though, and each of them can turn five minutes into a day.

PHP and Laravel. Statamic 6 requires PHP 8.3 and Laravel 12. A site on PHP 8.2 needs a server change first, which on shared hosting can mean a support ticket and a wait. A site on Laravel 10 or 11 needs a framework upgrade before Statamic can follow. Both are routine, but they're separate steps, each with its own testing.

Vue 3. The control panel moved from Vue 2 to Vue 3. If a site has no custom components and none of its addons touch the control panel, you don't need to do anything. If it has fieldtypes, widgets, or pages of its own, they need rewriting along the lines of Statamic's separate Vue migration guide. And for third-party addons, you depend on their authors. An addon that extends the control panel and hasn't been updated for Statamic 6 is the most likely reason a site can't move yet.

Time zones. Dates are still stored in the app time zone, but they now pass through UTC on their way to the control panel, which shows them in each editor's own time zone. If a site's app time zone is UTC, nothing changes. Everywhere else, check how dates look after the upgrade, especially date fields without a time. Until Statamic 6.17, released on May 8, those could show or save the wrong day depending on the time zones involved, so that's the minimum version to aim for.

Things that fail quietly

Two changes in the guide are marked low impact, and they're exactly the kind nobody notices until a client calls.

The first affects sites that keep users in a database instead of flat files. Statamic 6 brings two-factor authentication and passkeys into core, and both need new database tables and columns. The upgrade publishes two migrations for them, but someone still has to run php artisan migrate on each server and add a two_factor_confirmed_at cast to the User model. Skip that, and the site works fine until someone tries to set up two-factor login.

The second concerns super users. In Statamic 6, they automatically get every permission that belongs to Statamic, but no longer pass every authorization check in your own Laravel code. If a site has custom gates or policies and relies on super users getting through them, those checks now fail. The upgrade guide shows how to restore the old behavior with a Gate::before() hook, which is a deliberate choice you should make per site rather than by default.

Which sites to move first

With several sites to upgrade, I'd sort them by risk, not by client size.

Sites still on Laravel 10 or 11 come first. They're already without framework security fixes, and moving them to Laravel 12 is worth doing now even if the Statamic upgrade follows later. Statamic 5 supports Laravel 12, so that step can happen independently.

Next are the simple sites: no custom control panel code, only first-party addons or addons that already support Statamic 6, and flat-file users. They're the ones where the five minutes are realistic, and doing them early gives you a routine before the harder cases.

The hard cases come last but need the earliest planning. A site with custom fieldtypes or an addon that hasn't been updated yet needs either a rewrite or a decision about replacing the addon. That's where you need the client's time and budget, and that conversation takes longer than the work itself. Starting it in May leaves room. Starting it in November doesn't.

For each site, the same checks apply after the upgrade: log in as an editor and as a super user, open a few entries with dates, and look at the collection listings. Then try setting up two-factor login with a test account, and if the site has its own gates or policies, run through them as a super user. That covers everything above in about fifteen minutes.

A deadline is a planning tool

None of this is unusual for a major version. What makes it manageable is that the end date is known. Statamic publishes its support dates in advance, and they don't shift because a client is slow to reply or another project runs long. So the question isn't whether to upgrade a site, only when, and December is easy to plan backwards from.

The sites that cause trouble in December will be the ones nobody looked at in May.