"Do we have to lift and shift, or rebuild, to get on a current version of Sitefinity?"
I hear some version of that question often, usually from teams who've been told the platform is "a few versions behind" and are bracing for a number with a lot of zeros in it. The answer is usually "No," but it depends on the definitions, and a lot of the anxiety comes from the fact that "rebuild" means different things to different people.
So before you budget anything, it's worth slowing down on the vocabulary. Three words get used interchangeably in these conversations, and they describe three very different amounts of work, risk, and cost.
Let's get into the terms
An upgrade is an in-place version bump. You move from one Sitefinity release to a newer one, run the migrations, regression test, and deploy. You typically don't update the widgets or rethink your pages to change a version number. This is good. We get the latest and greatest from Sitefinity for not a ton of work. For most teams, staying current is routine maintenance, not a big project with a steering committee.
A lift and shift is a re-platform. The classic example is moving your UI layer from the legacy MVC or WebForms renderer onto Sitefinity's .NET Core renderer. Your design, information architecture, content, and behavior can all carry over, so you're not forced into a redesign you didn't bargain for. What changes is the foundation underneath: a modern, supported, faster-performing platform that opens up capabilities the old renderers can't.
A rebuild is where people tend to get nervous, and for good reason. Let's discuss two different kinds of rebuilds.
There are two kinds of "rebuild"
The first is a technical rebuild, which is really just the lift and shift in practice. Moving to the .NET Core renderer requires re-implementing your widgets and templates on the new framework: real work, but bounded work, scoped against the site you already have. Whether you're on MVC or older WebForms, you're re-platforming onto a modern foundation, not reinventing the site. Design, content, and behavior can carry over.
It doesn't have to be one high-stakes cutover, either. Sitefinity's hybrid rendering mode lets the legacy and .NET Core renderers run side by side, so you migrate a few widgets and pages at a time and validate them as you go. The idea is to start early and go slow: a steady program in the background of normal operations, not a deadline you're up against.
The second "rebuild" is a strategic rebuild, a reinvention. New design, new information architecture, new user experience. You're not re-platforming the site you have; you're starting over with a different site.
When a CTO hears "you'll need to rebuild your widgets to get to .NET," they can hear reinvention: the big, expensive redesign. But those are different projects. The first is engineering against what you already have. The second is a strategic bet that touches marketing, brand, and every stakeholder who has an opinion about the homepage. A lot of the "do we have to rebuild?" dread is someone bracing for the strategic rebuild when the answer is a technical rebuild.
When a true rebuild actually makes sense
Reinvention, the strategic kind, is a legitimate and sometimes excellent decision. But notice what tends to drive it. It's rarely the version number. It's usually a business event: a merger or acquisition that forces two web properties into one, a rebrand, a consolidation of a dozen microsites, or a genuinely new digital strategy that the current information architecture can't support. Those are real reasons to start over.
"We're four versions behind" usually isn't one of them. If your only driver is staying current, a reinvention is an expensive way to solve a problem that an upgrade, or at most a lift and shift, already solves.
Don't let drift turn a lift and shift into an archaeology project
All of this gets a lot easier the less you let the platform drift. A site that stays within a version or two of current tends to upgrade easily. A site that's been frozen for five years can become an excavation: dependencies no one remembers, customizations no one documented, and a migration that starts to look like a rebuild because so much has to be reverse-engineered first.
That's how teams manufacture the very dilemma they were afraid of. The drift creates the cost, and then the cost gets blamed on the upgrade.
The fix is unglamorous and continual: small, regular upgrades that keep you fresh, so the eventual tech update is a clean lift and shift instead of a slog. This is what an ongoing support retainer is for, the arrangement that keeps both your patches and your version current, which keeps your options open and your costs predictable.
For Sitefinity upgrades, it comes down to this: default to an in-place upgrade; lift and shift when the technology requires it; reinvent when the business genuinely calls for it. Three different decisions, three different price tags. Upgrades belong on a regular cadence; the other two should wait for a real reason, a technical need or a business one.
Good upgrade planning isn't about deciding between lift and shift or rebuild. It's about keeping your platform healthy enough that you rarely have to face the dramatic version of either one.
If you're staring at a version gap and trying to figure out which of these three conversations you're actually in, that's a conversation we're always happy to have.
Figure out which conversation you're actually in.
If you're staring at a Sitefinity version gap and trying to tell whether you need an upgrade, a lift and shift, or a true rebuild, we'll talk it through with you and help you scope the right one.
Talk to us about your Sitefinity upgrade arrow_forwardKevin Reed is Principal Solutions Architect at Springthrough. He spends most of his time helping mid-market teams keep their Sitefinity platforms current, stable, and a lot less dramatic than they expect.