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
