Get your Umbraco site fully supported again, without a full rebuild.
An outdated Umbraco build gets more fragile every month: security gaps, missing features, code nobody wants to touch. We move you onto a properly supported version, without starting from scratch.
You don't need a new website. You need this one properly looked after.
Whether you're the marketing lead who inherited a site nobody documented, the IT manager fielding security questions from above, or the owner who just wants the invoices to stop, an ageing Umbraco build is everyone's problem the moment something breaks.
We handle the whole upgrade path in-house: version upgrades, Umbraco Forms, third-party integrations and the .NET underneath it all. You get one team accountable end to end, not a developer who disappears once the database migrates.
Why Teams come to us?
“We're on an unsupported version and scared to touch it.”
We start with a proper technical audit, not guesswork, so you know exactly what's fragile before anything changes, and what breaks if you don't.
“Nobody knows what'll break if we upgrade.”
We map every integration, custom code block and Umbraco Forms setup before we start, so nothing gets discovered by accident halfway through the project.
“We got quoted once and the number kept moving.”
We scope the whole upgrade path upfront, version by version, so the number you're given at the start is the number you pay at the end.
“Our Umbraco Forms haven't been touched in years.”
We upgrade Umbraco Forms alongside the core CMS, testing every enquiry and booking form properly rather than assuming they'll just carry over.
The Gecko Way™
Our approach to successful projects
Before we talk versions, we talk to your team. What's on the site now, who built it, what's custom, what's a bolted-on package, and what nobody's touched since the last person left. We pull the current Umbraco version, the .NET version underneath it, every third-party integration and every Umbraco Forms setup into one clear picture. Most sites we take on have at least one piece of custom code nobody currently on the team fully understands, so we treat finding those as part of the job, not a nasty surprise for later. You end this phase with an honest account of what you're actually running, not a guess.
This is where we plan the actual upgrade path, not just the destination. Recent Umbraco versions upgrade cleanly in a single step, moving from Umbraco 12 to 13 is a good example, and jumps between Long-Term Support releases are often more direct than people expect. Older builds are a different story: Umbraco 7 to 8, for instance, was a full codebase rewrite, so that particular move has never really been an upgrade in the normal sense, it's a content migration, and we'll tell you plainly if that's what your site actually needs rather than quoting you for something that doesn't exist.
We're also explicit about where your current version sits: still receiving security patches, or genuinely past the point where anyone's fixing anything. We'll tell you plainly whether your version's still in its Support Phase or has already moved into the Security Phase, since that's the detail that actually drives urgency, not just the version number. Where the timing works, we'll also flag if it's worth waiting and landing straight on Umbraco 17 instead of 13, since jumping onto the newest LTS release in one move can sometimes save you a second project further down the line, and we'll do the same check again once an Umbraco 18 STS release follows it.
The upgrade itself happens in a staged environment first, never live on day one. We work through the path version by version, testing your integrations, your custom templates and your Umbraco Forms at each stage rather than crossing our fingers at the end. If your build needs a .NET version update alongside the CMS upgrade, which it usually does, that gets planned in as part of the same project, not discovered halfway through and re-quoted. Nothing goes live until we're confident it behaves exactly as it did before, just on infrastructure that's actually supported. For larger or more complex builds, particularly ones with custom blocks or bespoke templates, we'll often bring in tooling like Umbraco Deploy to move content and configuration between environments reliably, rather than relying on manual exports.
Newer Umbraco versions change how your editors actually work day to day, and we don't just hand that over and hope. If your upgrade brings in things like the Block Grid Editor for flexible layouts or Dynamic Root for content picking, we walk your team through what's genuinely different, not a generic back-office tour. We document what we've changed and why, so if someone new joins your team in a year, they're not starting from the same blank page you were. The goal is a smoother user experience for your editors from day one, not a system they're quietly afraid of clicking the wrong button in. For anyone moving onto Umbraco 14 or later, the backoffice itself now runs on web components rather than the older framework, so we'll walk through what that actually changes day to day, including anything visibly different in the Media Library, not just the page-editing screens.
An upgrade isn't a one-off fix if nobody plans the next one. We agree what "staying current" looks like for your site going forward, whether that's ongoing support, a check-in ahead of the next Umbraco LTS release, or simply making sure you know who to call before a version quietly slips out of support again. The goal is that this is the last panicked upgrade conversation you have. Whether that's a formal Umbraco Support arrangement or simply an annual check-in, the choice is yours, not something we assume for you.
What's Included in an Umbraco Upgrade
Umbraco Version Upgrades
Moving between major Umbraco versions properly, not just installing the latest package and seeing what breaks. We plan the actual umbraco upgrade path for your site: a single step like upgrading Umbraco 12 to 13 is usually straightforward, since Umbraco's recent Long-Term Support releases are built to upgrade into cleanly. Older sites need more care.
Anything as far back as Umbraco 7 involves a different kind of project entirely, since that codebase was rewritten from the ground up rather than upgraded incrementally, so we'll always tell you honestly whether you're looking at an upgrade path or something closer to a migration. Either way, we test each step before moving to the next, and we'll give you a straight answer on which version you should land on, usually a current LTS release, so you're not back here again in twelve months.
That's specifically because the jump from Umbraco 7 to Umbraco 8 involved a full rewrite of the underlying codebase, not because every legacy version is that dramatic. We've taken sites through the full range, from versions 7 to 17, covering both the smaller minor upgrades within a single release line and full major version upgrades between them, always following Umbraco's own upgrade guides as the starting point rather than reinventing the process.
We're already fielding early questions about Umbraco 17, and for sites currently sitting on 12 or 13, version 17 is likely to be a clean, direct next step when the time comes. Newer versions also open up headless features, so your content can be delivered via API to other apps or platforms down the line, useful even if it's not a day-one requirement.
Umbraco Forms Upgrade
Forms are often the part of a site nobody thinks about until they stop working. As part of your umbraco forms upgrade, we test every enquiry form, booking form and application form your site relies on, checking submissions still reach the right inbox, validation still behaves and any custom form logic still fires correctly.
Older Forms setups sometimes rely on workflows or field types that have changed between versions, and we'd rather catch and fix that in a staging environment than have you find out because a lead went missing. Some of that comes down to property editors changing between versions, which is exactly the kind of detail that's easy to miss without testing properly.
.NET & Infrastructure Upgrade
Umbraco runs on .NET underneath, and each Umbraco version is tied to a specific .NET version, so an outdated CMS almost always means outdated infrastructure too. We handle the .NET and hosting side alongside the CMS upgrade rather than treating it as a separate project, checking your hosting environment can actually support the target version before we start, not after something falls over.
This is also where we deal with anything IT-adjacent your internal team will want reassurance on, since it's the part they'll usually be asked about. Whether you're on Umbraco Cloud or self-hosted infrastructure, we'll review your hosting setup and check the underlying database schema against what the target version expects, since Umbraco itself runs on Microsoft technology under the hood, and that's often where IT teams want the most reassurance.
Third-Party Package & Integration Compatibility
Every plugin, package and integration your site relies on gets checked against your target version before we touch anything, from payment gateways and CRM connections to smaller packages you might not remember installing. Where a package doesn't have a direct equivalent for the newer version, we'll tell you honestly rather than quietly dropping the feature, and talk through whether it needs replacing, rebuilding, or simply isn't worth carrying forward.
This is usually where the real scope of an upgrade becomes clear, so we do it early. This covers everything from simple third-party packages to more involved API integrations your developers may have built directly against Umbraco's own APIs, and some of what we find are genuine community packages rather than commercially supported ones, which changes how we plan for their long-term upgrade path too.
Security & Long-Term Support Planning
There's a real difference between a version that's reached end of support, which still receives security patches, and one that's end of life, which doesn't get any maintenance at all. We're upfront about where your current build actually sits, because that changes how urgent this genuinely is, not just how nice it'd be to do.
Beyond the upgrade itself, we'll set out a straightforward plan for staying on a supported LTS version going forward, so security patching doesn't become something you only think about once a year when it's already too late. Umbraco's own lifecycle moves every release through a Support Phase, then a Security Phase, before it reaches end of life, and left unresolved, the security issues that build up during that Security Phase tend to compound instead of staying isolated to one part of the site.
This applies whether you're self-hosted or running on Umbraco Cloud, since security updates still need to happen either way.
Content, Editor Experience & Data Integrity
Newer Umbraco versions change what your editors see day to day, and we make sure that transition doesn't catch your team off guard. Where relevant, we'll walk through changes like the Block Grid Editor for flexible content layouts, or Dynamic Root for content picking, and how they affect the templates your team actually uses.
Throughout the upgrade, protecting your existing content is the priority: every page, image and content type gets checked against the upgraded site before go-live, so nothing gets silently lost or reformatted in the process. Where it applies, this also covers Macros migration and moving older Nested Content setups across to Block List and Blocks in the Rich Text Editor, the newer, more flexible way of handling custom blocks within a page.
If your upgrade lands you on Umbraco 14 or later, we'll also walk your team through the new backoffice architecture, since it's now built with web components rather than the older framework, which changes how the Content Tree and Media Library actually feel to use day to day. Most of this shows up as content structure updates behind the scenes, work your editors won't need to think about, rather than anything they'll be asked to redo.
What's Included in an Umbraco Upgrade
Umbraco Version Upgrades
Moving between major Umbraco versions properly, not just installing the latest package and seeing what breaks. We plan the actual umbraco upgrade path for your site: a single step like upgrading Umbraco 12 to 13 is usually straightforward, since Umbraco's recent Long-Term Support releases are built to upgrade into cleanly. Older sites need more care.
Anything as far back as Umbraco 7 involves a different kind of project entirely, since that codebase was rewritten from the ground up rather than upgraded incrementally, so we'll always tell you honestly whether you're looking at an upgrade path or something closer to a migration. Either way, we test each step before moving to the next, and we'll give you a straight answer on which version you should land on, usually a current LTS release, so you're not back here again in twelve months.
That's specifically because the jump from Umbraco 7 to Umbraco 8 involved a full rewrite of the underlying codebase, not because every legacy version is that dramatic. We've taken sites through the full range, from versions 7 to 17, covering both the smaller minor upgrades within a single release line and full major version upgrades between them, always following Umbraco's own upgrade guides as the starting point rather than reinventing the process.
We're already fielding early questions about Umbraco 17, and for sites currently sitting on 12 or 13, version 17 is likely to be a clean, direct next step when the time comes. Newer versions also open up headless features, so your content can be delivered via API to other apps or platforms down the line, useful even if it's not a day-one requirement.
Umbraco Forms Upgrade
Forms are often the part of a site nobody thinks about until they stop working. As part of your umbraco forms upgrade, we test every enquiry form, booking form and application form your site relies on, checking submissions still reach the right inbox, validation still behaves and any custom form logic still fires correctly.
Older Forms setups sometimes rely on workflows or field types that have changed between versions, and we'd rather catch and fix that in a staging environment than have you find out because a lead went missing. Some of that comes down to property editors changing between versions, which is exactly the kind of detail that's easy to miss without testing properly.
.NET & Infrastructure Upgrade
Umbraco runs on .NET underneath, and each Umbraco version is tied to a specific .NET version, so an outdated CMS almost always means outdated infrastructure too. We handle the .NET and hosting side alongside the CMS upgrade rather than treating it as a separate project, checking your hosting environment can actually support the target version before we start, not after something falls over.
This is also where we deal with anything IT-adjacent your internal team will want reassurance on, since it's the part they'll usually be asked about. Whether you're on Umbraco Cloud or self-hosted infrastructure, we'll review your hosting setup and check the underlying database schema against what the target version expects, since Umbraco itself runs on Microsoft technology under the hood, and that's often where IT teams want the most reassurance.
Third-Party Package & Integration Compatibility
Every plugin, package and integration your site relies on gets checked against your target version before we touch anything, from payment gateways and CRM connections to smaller packages you might not remember installing. Where a package doesn't have a direct equivalent for the newer version, we'll tell you honestly rather than quietly dropping the feature, and talk through whether it needs replacing, rebuilding, or simply isn't worth carrying forward.
This is usually where the real scope of an upgrade becomes clear, so we do it early. This covers everything from simple third-party packages to more involved API integrations your developers may have built directly against Umbraco's own APIs, and some of what we find are genuine community packages rather than commercially supported ones, which changes how we plan for their long-term upgrade path too.
Security & Long-Term Support Planning
There's a real difference between a version that's reached end of support, which still receives security patches, and one that's end of life, which doesn't get any maintenance at all. We're upfront about where your current build actually sits, because that changes how urgent this genuinely is, not just how nice it'd be to do.
Beyond the upgrade itself, we'll set out a straightforward plan for staying on a supported LTS version going forward, so security patching doesn't become something you only think about once a year when it's already too late. Umbraco's own lifecycle moves every release through a Support Phase, then a Security Phase, before it reaches end of life, and left unresolved, the security issues that build up during that Security Phase tend to compound instead of staying isolated to one part of the site.
This applies whether you're self-hosted or running on Umbraco Cloud, since security updates still need to happen either way.
Content, Editor Experience & Data Integrity
Newer Umbraco versions change what your editors see day to day, and we make sure that transition doesn't catch your team off guard. Where relevant, we'll walk through changes like the Block Grid Editor for flexible content layouts, or Dynamic Root for content picking, and how they affect the templates your team actually uses.
Throughout the upgrade, protecting your existing content is the priority: every page, image and content type gets checked against the upgraded site before go-live, so nothing gets silently lost or reformatted in the process. Where it applies, this also covers Macros migration and moving older Nested Content setups across to Block List and Blocks in the Rich Text Editor, the newer, more flexible way of handling custom blocks within a page.
If your upgrade lands you on Umbraco 14 or later, we'll also walk your team through the new backoffice architecture, since it's now built with web components rather than the older framework, which changes how the Content Tree and Media Library actually feel to use day to day. Most of this shows up as content structure updates behind the scenes, work your editors won't need to think about, rather than anything they'll be asked to redo.
"We map every integration and custom template before we touch a thing, so nothing breaks after we've moved on."
Michael Cox, Full Stack Developer at Gecko
Umbraco Upgrade Case Study
[PLACEHOLDER: no confirmed Umbraco upgrade case study with verified metrics currently exists in the reference material. Draft paragraph below uses bracketed placeholders throughout and should not be published as-is.]
We recently took [CLIENT NAME], a [SECTOR] organisation running an unsupported version of Umbraco, through a full upgrade path onto a current Long-Term Support release. The project included [X] version steps, a full Umbraco Forms upgrade and compatibility checks across [X] third-party integrations, completed with zero content loss and no downtime to the live site.
An Umbraco upgrade moves your site from an older version of the CMS onto a newer, supported one, along with the .NET framework it runs on, since the two are tied together version by version. It's different from a full rebuild: your content, templates and structure carry across rather than being recreated from scratch. Depending on how far behind your current version is, this might be a single step or a longer upgrade path through several intermediate versions, each one tested before we move to the next. Alongside the core CMS, we also check Umbraco Forms, any custom code and every third-party integration your site depends on, since these are usually where problems actually surface if they're not handled properly. Umbraco itself is built as a content management system with a flexible content structure, made up of content types, templates and property editors that define how your editors actually work with each page.
It's a distinction worth understanding, because it changes how urgent an upgrade genuinely is. A version that's reached end of support still receives security patches for a defined period, so there's some breathing room. A version that's end of life gets no maintenance at all, meaning any security vulnerability discovered from that point on simply never gets fixed. Sites running end of life Umbraco versions are running on infrastructure with known gaps that nobody's patching. We'll tell you plainly which category your current version falls into before recommending anything. Umbraco HQ formalises this with a Support Phase followed by a Security Phase for every release, so you can check exactly where any given version sits rather than relying on guesswork.
We'll usually recommend landing on a current Long-Term Support release rather than whatever's newest, so you get stability without needing another upgrade project next year. The right umbraco upgrade path depends on where you're starting from. A jump like upgrading Umbraco 12 to 13 is usually straightforward, since Umbraco's recent LTS releases are built to upgrade into directly. Older builds need more planning, since the further back you go, the more likely you are to hit a version that was a genuine rewrite rather than an incremental step. We map that out during the Evaluate phase and talk you through exactly why we're recommending it, rather than just handing you a version number. Right now that's Umbraco 13, which is still receiving security patches, with Umbraco 17 arriving as the next Long-Term Supported release later this year. Umbraco 14 exists as a shorter-term release, useful if you need a specific feature early, but not something we'd recommend building your long-term CMS version around, and the same goes for Umbraco 18 STS once it follows version 17.
Yes, but we don't just assume it and move on. As part of every Umbraco Forms upgrade, we test each form on your site individually, checking submissions still reach the right place, validation still works as expected, and any custom form logic still fires correctly. Older Forms setups occasionally rely on field types or workflows that have changed between versions, which is exactly the kind of thing we'd rather catch and fix in a staging environment than have you discover because an enquiry went missing.
For most sites, upgrading. A rebuild means recreating your content, structure, integrations and editor training from zero, which costs considerably more than moving your existing site onto a supported version. The exception is a site that's been so heavily customised, or is running on a version so old it was fundamentally rewritten since, that a rebuild genuinely works out simpler, and we'll tell you honestly if that's what we find during the Evaluate phase rather than pushing an upgrade that isn't the right call. Either way, you get a proper answer before you commit to either route, not a default sales pitch for the bigger project. It's also where genuine technical debt shows up. Sites carrying legacy Umbraco code from three or four versions back tend to need more care, but that's still rarely a reason to rebuild outright.
It depends entirely on how far behind your current version is and how much custom code and integration work your site carries. A single-step upgrade, like moving from Umbraco 12 to 13, is usually a matter of weeks, since Umbraco's own upgrade tooling handles most of the heavy lifting between supported LTS releases. A longer path from an older version, with more intermediate steps and more legacy code to work through, takes longer, and we'll give you a realistic timeline once we've actually seen your build during the Gather phase, rather than a generic estimate before we've looked at anything. For larger builds we'll often use tooling like Umbraco Deploy to move content and configuration between environments cleanly, which keeps things faster and more reliable than doing it by hand. If you're on Umbraco Cloud, deployment between environments is usually a little quicker too, since the tooling handles a lot of the environment management for you.
That's exactly what the Gather and Evaluate phases exist to prevent. Every piece of custom code, every third-party package and every integration your site relies on gets checked against your target version before we start work, not discovered as a problem partway through. Where something won't carry across cleanly, we'll tell you during scoping, along with what it'll take to fix, rather than quietly dropping a feature or re-quoting you once we're already underway. This also covers any API changes that might affect integrations built against Umbraco's Management API. We check custom plugins, custom extensions and any front-end code or NuGet packages your team has added over the years, including community packages, since all of it is just as likely to need attention as the core CMS itself.
Nothing, until something does, and by then it's usually a security incident or a feature that quietly stops working. Sites left on unsupported versions often end up needing temporary workarounds instead, things like penetration testing or IP restrictions to manage the risk, which cost nearly as much as the upgrade itself without actually fixing anything. Beyond security, staying on an old version tends to mean missing features your editors would genuinely benefit from, and it gets harder to find developers willing to work confidently in an outdated back office. The security issues that build up on an unpatched version don't wait for a convenient time to surface, and the potential issues extend beyond the CMS itself once other parts of your stack fall out of step. Once you're sitting in the Security Phase rather than full support, that clock is already ticking, even if nothing's visibly broken yet.
It depends what "upgrade" means for that specific version, and we'll be straight with you about it rather than stretching the word to fit. Some older versions step forward cleanly through a defined upgrade path. Umbraco 7 is a genuine exception: the codebase underneath 8 was rewritten so fundamentally that there's no direct upgrade route between them, which means moving off Umbraco 7 is really a content migration to a current version, not an incremental upgrade. We're happy to take that project on, we just won't call it something it isn't, since that changes both the approach and the cost. In practice that means Umbraco 8 marked a genuine platform change, not just a version bump, which is why we treat that specific jump differently to something like 12 to 13.
We don't disappear the moment the new version is live. We keep a close eye on the site over the days that follow to catch anything that isn't behaving exactly as it should, and we'll talk you through what staying current looks like going forward, so this doesn't become another unsupported version in a few years' time. Some clients prefer a formal Umbraco Support arrangement from day one, others prefer to wait and see, and either way works for us. If you'd like to talk through what an upgrade would actually involve for your specific site, book a discovery call and we'll take it from there.
