What does a migration from Umbraco 13 to 17 cost?

In two recent estimates for sites with several external integrations: 60 to 64 hours. A site without integrations sits well below that — the testing phase is the biggest line and shrinks the most.

Why do two thirds of the hours go into testing?

Because the upgrade itself is automated on our platform. The risk of a migration is not in the CMS but at the edges: external integrations, e-mail, forms and everything that relies on them. Those are verified one by one, followed by a full acceptance test before anything goes live.

What does a migration from Umbraco 8 or 10 cost?

More than from 13, and how much more depends on the custom code. Backoffice extensions from that generation run on technology that no longer exists in Umbraco 17 and have to be rebuilt. A precise number only exists after the inventory — which is exactly why that phase exists.

How long does a migration take?

The lead time is not determined by the upgrade but by the test and acceptance rounds and scheduling the content freeze around go-live. Count in weeks, not days — and plan backwards from a deadline such as the end-of-life date of your version.

Do I get a fixed price?

Yes. After the inventory we lock down a migration plan with a fixed price and a fixed end date. Only third-party work (for instance an external vendor adjusting an integration) falls outside it.

Can my content move 1-to-1?

Almost always: content, media and users move over automatically. The exception is content built in editors that no longer exist in the new version — that gets restructured. What falls under that is known after the inventory, not afterwards.

Count in hours and factors — here are both

What does an Umbraco migration cost?

The question everyone asks and hardly any agency answers. So we will: in two recent estimates for a migration from Umbraco 13 to 17, both for sites with several external integrations, we arrived at 60 to 64 hours. Below is where those hours go — and which factors push the number up or down for your site.

Where the hours go

Phase	What happens	Indication
1. Inventory	Scope, review packages and custom code, check integrations, lock down the migration plan	±8 hours
2. Environment and migration base	Set up hosting, migrate database, media and configuration with our migration scripts	±2 hours
3. Upgrade to Umbraco 17	Run the upgrade, resolve compatibility issues, reconnect forms	±2 hours
4. Integrations and testing	Test every external integration, e-mail, internal test round, test scenario and acceptance test	40+ hours
5. Go-live and rollback	Content freeze, final content sync, go-live with a prepared rollback scenario	±4 hours
6. Aftercare	Monitoring, logs, small issues, documentation and handover to regular maintenance	±4 hours

Notice the most striking part? The upgrade itself is 4 of the 60 hours. Database, media, content and configuration move with our standardised migration scripts — that part is automated, as it should be. Two thirds of the budget sits in the phase you cannot automate: verifying that everything still works. Every integration, every form, every e-mail, and a full acceptance test before anything goes live.

What makes a migration more expensive

Version distance. From 13 to 17 is the cheapest route. Coming from 8 or 10 there is more to rebuild — backoffice customisations from that generation run on technology that no longer exists in Umbraco 17. Read how that went in our case study: migrating from Umbraco 10 to 17.
External integrations. Every integration (CRM, HR systems, analytics, feedback tools) has to be retested — the biggest line in the table above. See Umbraco integrations for the hours per type.
Forms with data. Carrying submissions over within their retention period takes care; deleting them is usually not an option.
Content that cannot move 1-to-1. Content built in editors that no longer exist has to be restructured; the inventory tells you what that covers.

What makes a migration cheaper

Little custom code and standard packages — the closer to standard Umbraco, the smaller phase 3.
A standardised platform. Our hosting and deployment are ready as a product; no hours go into server setup or deployment pipelines.
Starting on time. Umbraco 13 reaches end-of-life on 14 December 2026. With room in the planning you get to choose what moves, what gets rebuilt and what can go — urgency makes everything more expensive.

Fixed price, fixed end date

After the inventory (phase 1) we know what is there and what depends on it. From that point we work with a migration plan with a fixed end date and a fixed price; only third-party work outside our control falls outside it. No open end, no surprises afterwards.

Frequently asked questions about migration costs

: In two recent estimates for sites with several external integrations: 60 to 64 hours. A site without integrations sits well below that — the testing phase is the biggest line and shrinks the most.
: Because the upgrade itself is automated on our platform. The risk of a migration is not in the CMS but at the edges: external integrations, e-mail, forms and everything that relies on them. Those are verified one by one, followed by a full acceptance test before anything goes live.
: More than from 13, and how much more depends on the custom code. Backoffice extensions from that generation run on technology that no longer exists in Umbraco 17 and have to be rebuilt. A precise number only exists after the inventory — which is exactly why that phase exists.
: The lead time is not determined by the upgrade but by the test and acceptance rounds and scheduling the content freeze around go-live. Count in weeks, not days — and plan backwards from a deadline such as the end-of-life date of your version.
: Yes. After the inventory we lock down a migration plan with a fixed price and a fixed end date. Only third-party work (for instance an external vendor adjusting an integration) falls outside it.
: Almost always: content, media and users move over automatically. The exception is content built in editors that no longer exist in the new version — that gets restructured. What falls under that is known after the inventory, not afterwards.