It all started with Umbraco 4
Like I said, when I jumped in, Umbraco 4 was the latest release. To new folks, that seems ancient. And in software years, it really is. The backoffice looked nothing like it does today, the tech stack was its own thing, and deploying a site was a completely different ordeal back then.
But I was looking for a replacement for my own written CMS, called WebControl, because extending and maintaining a complete CMS on your own is something else. And Umbraco seemed to have about the same philosophy as I had envisioned for WebControl.
What grabbed my attention was how flexible Umbraco felt. Unlike a lot of other content management systems, it didn’t force me to work a single way. Instead, it handed me the toolbox and said, “Go ahead, figure out what you want to build” That was pretty exciting because it was exactly the idea behind WebControl.
Of course, all that freedom allows more ways to mess up. Looking back, I can see I was still learning what “good” content modeling actually meant. I could build stuff that worked, but keeping it organized or maintainable? That took me much longer to get right. There’s a world of difference between making something function and making sure someone else can live with it years later. But I’m pretty sure every developer learns that one the hard way.
Over time, I realized the first thing you ask isn’t “Can Umbraco do this?” but “Should we do this at all?” Experience eventually shifts your priorities: early on, you just want proof that something is possible. Get a few years in, and you start picturing the client (editor) who will use it, the developer who’s got to maintain it, and the poor soul responsible for the upgrade nightmare.
Confession: I have absolutely created a “TestPage” or “TestDocument” that grew into an essential part of a site. That kind of thing happens to all of us. Some lessons you learn over and over.
The version that never was: Umbraco 5
Next, there’s the curious case of Umbraco 5. Sure, it existed and it was a huge rewrite and a bold new direction for the CMS. But in the end, the project got put on ice, and development shifted to Umbraco 6. That left a strange gap in Umbraco’s timeline.
If you’re new, you might scroll through releases and wonder, “Where’s 5?” If you’ve been around, you probably have a story about it. I think of it like the missing 13th floor in a hotel: you know it was meant to be there, but everyone uses the elevator happily and quietly skips over it.
So yeah, I will just repeat what Umbraco says about it “we don’t talk about version 5”.
Umbraco 6 and a growing ecosystem
With Umbraco 6, the platform grew up a lot. More agencies picked it for big projects, more packages popped up, and the community started turning into a core part of the experience as you can read in Sebastiaan’s post.
This is also the era when I figured out what I wanted from a CMS. Building a website “that works” stopped being enough. The content model had to make sense. Editors needed a smooth ride. The code needed to be readable six months down the road. And the system had to stay flexible, ready for whatever wild new idea a client would throw at us.
Any experienced CMS developer knows this story: nothing stays simple for long. Ten pages turn into hundreds, simple models get complicated, marketing wants more landing pages, someone invents a “reusable element”, more and more integrations were needed and before you know it, the template you always use is becoming the backbone for a monster project.
Umbraco’s flexibility helped it scale, but it also forced me and other developers to make solid decisions or risk painting themselves into a corner. That tug-of-war between freedom and responsibility is a constant theme in my Umbraco journey.
Umbraco 7: when it started feeling familiar
Umbraco 7 was a big chapter. By now, the CMS felt mature. The community kept growing. Agencies and developers had years of experience with it. And lot of those old Umbraco 7 sites? They’re still up, quietly doing their jobs in the background, occasionally spooking a developer when someone suggests an “easy” update. Heck, we’ve even got one single Umbraco 6 website still running strong.
For me, Umbraco 7 was when I stopped just using the platform and wanting to really start understanding it. There’s a big difference between “knowing about” something and building real intuition. After a while, patterns jump out at you. You look over a content model and can spot future headaches immediately. You recognize where the customizations hide. And you know exactly which bits are simple and which ones were left by someone who’s long gone and (of course) didn’t document a thing.
A lot of that knowledge comes from experience (and a fair bit of trial and error). You learn by building, breaking, fixing, and sometimes inheriting someone else’s maze of a project and wondering what they were thinking.
Then one day, you realize someone else is probably scrolling through your old code, thinking those exact same thoughts.
Umbraco 8 and the age of compositions
Umbraco 8 brought a big shift in how we thought about content modeling: compositions. Finally, you could build reusable blocks and share them across document types instead of creating giant, bloated models with every possible property “just in case.”
Great idea in theory, and in practice too, but if you give a developer a flexible feature, they’ll push it to its limits. Suddenly, you’re composing everything: titles, images, even two checkboxes and a dropdown — all get their own compositions. Okay, maybe that’s a stretch, but not by that much.
The point is, the platform kept changing, and so did how we used it. That’s why looking back at old projects can feel so strange. What seemed brilliant years ago can look convoluted today, and things we ignored then sometimes become pivotal. The tech grows, but so do the developers using it.
Then the technology underneath Umbraco changed
One of the biggest shakeups was the move from the classic .NET Framework world to modern .NET and ASP.NET Core. This wasn’t just a package update. It was a total change under the hood. Suddenly, you needed to think about dependency injection, middleware, hosting models, Program.cs, and all the NuGet packages that come with the territory.
For longtime users, it was both exciting and a little daunting. The skills you’d built still mattered, but you had to adjust them for a new landscape. Honestly, I loved it.
Now, Umbraco wasn’t just its own little kingdom. It became part of the broader .NET world. You could take lessons from other ASP.NET Core projects and use them in Umbraco or vice versa. Being a good Umbraco developer now meant being a good .NET developer.
I think that’s the way it should be. A CMS shouldn’t shield you from learning the platform beneath it. If anything, it should let you put that knowledge to good use.
Umbraco 9, 10, 11 and 12: getting used to the new world
Then came Umbraco 9, 10, 11, and 12 — a stretch that feels, in hindsight, like one long transition phase.
Each version brought its own changes, challenges and edge cases. Sometimes you’d have to double-check which version you were on before choosing a package or following some docs.
What mattered most was that the foundations were settling. The “new” Umbraco started feeling solid instead of experimental.
This stretch taught me something else about tech: you can’t coast, no matter how much experience you have. Doing the same thing for years doesn’t mean you can stop learning. The concepts last, but the tools keep shifting.
That’s probably why Umbraco keeps me interested. The learning never stops, but it’s not so extreme that you lose your footing.
Umbraco 13: a little bit of stability
Reaching Umbraco 13 felt like a huge milestone for me. Now the CMS was firmly on modern .NET. The architecture held up. The ecosystem thrived. It finally felt like a foundation you could rely on for new projects. Plus, we got long-term support (LTS).
Anyone who’s been through enough upgrades understands why LTS is a big deal. As a junior developer, a new big release is pure buzz. But after you’ve spent a weekend fighting an upgrade gone sideways, you begin to really appreciate a version that just… works. Sometimes “boring” is perfect.
A stable deployment is great. A smooth upgrade is a dream. Production doing exactly what you expect is a blessing.
Umbraco 13 let developers build with confidence, while the platform itself kept moving forward. Stability plus innovation turns out to be a pretty good formula, especially if you’re responsible for websites that don’t just vanish six months after launch.
And now we’re at Umbraco 17 and 18
Which brings us to the present. Umbraco 17 and 18 are a long way from the Umbraco 4 I started with, but deep down the heart of it still feels the same. The platform keeps evolving, the tech keeps getting more advanced, and new features have changed how we think about content modeling and management.
I’m particularly intrigued by the Library and Elements features, because they tackle one of the oldest Umbraco questions: how do you model content in a way that actually stays flexible, clean, and understandable?
And let’s not forget about all the fantastic new AI features that are now available as packages. The things we’ve built at ipsis already are worth a blog post on there own.
My answer to that has definitely changed. I started out always thinking, “How do I make this work?” These days I care a lot more about whether the developers of my team (and also editors) will actually be able to make sense of what I built, even years down the road.
That’s probably the biggest change for me, even more than any single feature. When I started with Umbraco it was all about possibilities. Now, I focus on consequences.
Sure, I can build it — but should I?
Yes, I can make the editor configure every option — but do they need to?
Yes, I can spin up another document type — but is it really helping?
These are questions I never thought about at the start; you only start asking them once you’ve lived through enough project maintenance.
So why am I still using Umbraco?
After all those versions and that much time, it’s a good question: why stick with Umbraco?
Today, there are loads of options out there. Headless platforms, SaaS products, page builders, and new frameworks popping up every week. There’s always something shinier trying to grab your attention.
So why am I still here?
It would be easy to say, “Because I know Umbraco inside out.” And yeah, comfort and experience matter. When you’ve been around long enough, you know the strong spots, the rough edges, and the weird old code you have to tiptoe around.
But that’s not enough for me.
I’ve stuck with Umbraco because the balance just works. There’s tons of freedom for developers, but not so much complexity that it gets in your way. Editors get a strong, flexible backoffice instead of a straitjacket. You can launch something simple or build a huge, sprawling platform.
The best part?
It doesn’t force you into a narrow box. I can plug it into other systems, extend what I need, use modern .NET practices, and actually make good choices about content modeling—without the CMS fighting me every step.
That flexibility is still a big deal to me. But honestly, there’s another reason, and it’s not about technology.
The community matters
The Umbraco community is one of the big reasons I’ve stayed connected all these years.
I’ve learned a ton from other Umbraco people. Through blogs, packages, GitHub, the docs, and just swapping stories online and in person. So many times, somebody out there built the thing I was stuck on, or explained it in a way that finally made it click in my head.
And now, after a decade-plus, I find myself paying back some of that; writing blog posts, sharing tricks and talking online about what I’ve learned.
That’s part of the magic. Umbraco isn’t just tech and docs. It’s full of real people who actually want to help.
Going to my first Codegarden in 2026 drove this home. I went to learn, meet folks, soak up the atmosphere, and, no surprise, left with a new appreciation for what the platform really is. APIs and content models matter, sure, but the community is the soul of it.
That’s why “The Friendly CMS” doesn’t feel like just a line in the marketing copy. After ten years, that still means something to me.
Looking back makes me curious about what’s next
One of the funny things about working in software development is how we’re almost always focused on what’s next. We’re always thinking ahead; What’s the next release? When does the new .NET version arrive? Which AI tool should we try? What new features do we need to pick up? What system do we need to upgrade now? There’s always something waiting just around the corner.
I wasn’t expecting it, but when I stepped away from work for a bit, I got this rare chance to look backward for once. My journey with Umbraco probably started somewhere in 2012 or 2013, working with Umbraco 4. Then I kept going through Umbraco 6 and 7, spent time working with Umbraco 8 and its whole approach to compositions, and witnessed the big shift as everything moved toward modern .NET. From there, I followed right along with Umbraco 9, then 10, 11, 12, 13, and here I am now, talking about Umbraco 17 and 18.
When I actually lay that all out, it sounds a bit wild. More than ten years with a single CMS! But, you know what? Somehow, after all this time, I’m still interested in it. That realization might be the most important thing I picked up while taking this little trip down memory lane.
It’s not like I stuck with Umbraco just because it was the first CMS I learned. If that were the only reason, I probably would’ve moved on ages ago. I’m still using it because, honestly, I think it’s just a really good CMS. I love how flexible it is for developers like me and the editors that uses it. I love the community. And I genuinely get excited whenever a new version drops and changes the way I think about building websites. That’s a pretty good sign, especially after 10+ years.
I have no clue what Umbraco will look like another decade from now. Maybe we’ll be at Umbraco 28. Maybe AI agents will be doing all our website building for us. Maybe, just maybe, we’ll have settled the eternal debate over naming conventions for document types. Well, okay, maybe let’s not get too optimistic.
But here’s what I do know: I’m honestly curious about wherever Umbraco goes next. Because after more than a decade, Umbraco isn’t just a CMS I know how to use. It’s something I’ve grown alongside, a technology I’ve been on a journey with. And I think that’s probably why I’m still here.