Skip to main content

Boot failure: the migration plan "UmbracoForms" does not support migrating from state "6149738f-25bd-44ac-9c1d-d66bbe9d4e2b"

Why a site stamped by Forms 13.9.9 fails to boot on other Forms versions, which versions are safe to upgrade to, and why the umbracoKeyValue workaround must not be used.

Written by Joana Knobbe

Type: Known Issue
Category: Umbraco Forms > Upgrading
Tags: UmbracoForms migration plan, does not support migrating from state, 6149738f-25bd-44ac-9c1d-d66bbe9d4e2b, BootFailedException, boot failed, Forms 13.9.9, Forms 17.5.0, Forms 18.1.0, package migration, umbracoKeyValue, upgrade v13 to v17

Product: Umbraco Forms
Version: Databases that have run Forms 13.9.9 or later on the v13 line


Summary

Status: Fixed in Forms 17.5.0 and 18.1.0.

If your site fails to boot with The migration plan "UmbracoForms" does not support migrating from state "6149738f-25bd-44ac-9c1d-d66bbe9d4e2b", your database has been stamped by Forms 13.9.9 and the Forms build now running does not recognise that stamp. The fix is to move to a Forms version that does. Do not try to fix this by editing the database.

Symptoms

  • The site returns an error on every request, front end and back office, and does not recover on restart, redeploy or a new environment.

  • The error is Umbraco.Cms.Core.Exceptions.BootFailedException: The migration plan "UmbracoForms" does not support migrating from state "6149738f-25bd-44ac-9c1d-d66bbe9d4e2b".

  • On CMS 13 the same error appears without the plan name: The migration plan does not support migrating from state "6149738f-25bd-44ac-9c1d-d66bbe9d4e2b".

  • The project builds and boots without problems locally, against a different database.

  • Nothing in your own recent changes looks related. The site may have been running normally for days.

If all you can see is Umbraco is not yet ready. Level: BootFailed with no exception, see Boot failure shows no error details when debug mode is off first.

Cause

Umbraco Forms records how far its database migrations have run as a state value. Forms 13.9.9 introduced a new state on the v13 line, 6149738f-25bd-44ac-9c1d-d66bbe9d4e2b. That state was not initially added to the migration chains on the other product lines, so builds on those lines cannot recognise it and refuse to continue.

Nothing fails while the site stays on 13.9.9 or later within v13. The failure needs a second event, and it can arrive from either direction:

  • Going forward. The site upgrades from v13 into a Forms version whose chain lacks the state: any 14.x, 15.x or 16.x release, 17.0.0–17.4.8, or 18.0.0–18.0.6.

  • Going backward. A deployment from a branch that was created before Forms 13.9.9 was released pins Forms 13.9.8 or earlier. This is easy to miss, because it looks like an ordinary deployment of unrelated changes. Check whether your branch pins a Forms version in its project file or Directory.Packages.props.

Which versions are affected

Safe to run or upgrade to

Forms 13.9.9 and 13.9.10 (staying on v13) · 17.5.0 and later · 18.1.0 and later

Will fail

Forms 13.9.8 and earlier · all 14.x · all 15.x · all 16.x · 17.0.0–17.4.8 · 18.0.0–18.0.6

There is currently no v16 release containing the fix, so a database stamped by 13.9.9 cannot be upgraded to Umbraco Forms v16 at this time.

Solution

If you are upgrading from v13

Target Forms 17.5.0 or later, or 18.1.0 or later. Those releases understand the state and run the upgrade normally, with no database intervention. If your upgrade has already failed, changing the target Forms version and deploying again is the fix.

If a deployment downgraded Forms below 13.9.9

Point the branch back at Forms 13.9.9 or later and deploy again. Do not resolve this by staying on the older Forms version.

Do not edit umbracoKeyValue

A workaround has been circulating that involves clearing the Forms value in the umbracoKeyValue table, or clearing the whole table. Please do not do this.

  • Clearing the value to an empty string does not work. The site fails to boot with the same class of error.

  • Deleting the row makes Forms re-run its entire migration chain from the beginning. Two of those steps are not safe to run twice. One of them can shift every Forms date, including submission timestamps and workflow audit trails, by your timezone offset a second time, with no error and no way to spot it afterwards. Another fails with Cannot insert duplicate key row in object 'dbo.umbracoNode' with unique index 'IX_umbracoNode_UniqueId'.

  • Clearing the whole table re-runs the migrations of every installed package as well, not only Forms.

If you have already applied this workaround, please open a support ticket and say so, including which environments it was run on. There are checks we can help you run.

If you are still stuck

If you are already on Forms 17.5.0+ or 18.1.0+ and still see this error, or you cannot move off an affected version, open a support ticket with:

  • the full exception from the log file;

  • your CMS, Forms and Deploy versions, and the versions you upgraded from;

  • which environment it happened on, and whether any database changes have been made to work around it.

Recommended documentation


AI + humans generated. Last updated on September 08, 2026

Did this answer your question?