CMS going End of Life – 3 steps towards lower risk version upgrading
It can get expensive if you're forced to upgrade from Sitecore 8 and Umbraco 7, when they soon go "end of life" 💀
But not necessarily. By building a separate frontend and decoupling your data sources from the current solution, you can de-risk the version upgrade that many are facing right now. Check out how 👩🎓
CMSs nearing End of Life 💀
All in one box: Handle it before Death does
Several Danish authorities such as municipalities, government agencies and ministries are running on Sitecore 8, which will be phased out before the end of 2023. The same applies to Umbraco 7 solutions, which will be phased out in September 2023. This means that the version no longer will be maintained, and security holes won't be closed. This poses a considerable security risk, and the problem is of course no less when we’re talking about public authorities that often handle sensitive personal information.
Therefore, anyone who is still using these versions should pull on the sprinter clothes and either upgrade to a newer Version or choose a different CMS. But obviously it’s not as easy as just that.
Everything in one box
Monoliths are more than just pros
An upgrade to newer versions or a move to another CMS is typically both complex and expensive. Not least because many of the solutions are built as monoliths in one single box, where many integrations, processes and user experiences go through these versions. It is almost unmanageable, and often the effort does not feel able to match the yield.
In a monolith, the entire IT architecture is gathered in one "box". All integrations and systems are pooled together, and the frontend and backend are conjoined. It can have lots of benefits – but also derived challenges. Especially when it comes to upgrades, as all elements are built together and thus are interdependent. This can result in the entire system crashing if just one component is out of order.
Therefore, it can be hugely cumbersome to upgrade the existing solution as you have to consider all the dependencies in the upgrade. In addition to the cost of a cumbersome upgrade, you might need to add the license price, which is certainly not insignificant in limited budgets.👇
Minimise the risk of your upgrade before upgrading or changing your system
1-2-3 with due care
As described, there are plenty of challenges to a monolith. And the challenges will not pass. It will always be complex to upgrade to new versions if some of these dependencies haven’t been disconnected from each other. However, there are ways to handle the upgrade that are far more flexible and far less risky.
We recommend a process in three separate steps, so you ensure that your entire organisation and your users are calmly onboarded – and that you stay ahead of both security, uptime, and user experience. The three-part process should give you far more control at lower cost, and it will also ensure that future upgrades will be simpler.
The key to a successful process is to separate the many dependencies so that you can manage each component more controlled and standardised.
The process is briefly described below.
1: Build a new frontend
Make yourself look good 👩🎨
The first step is to build a new, decoupled frontend. By decoupling your frontend, you remove complexity from your current solution, which thus becomes simpler to upgrade. The separate frontend will also be more flexible, and you can focus on creating a strong user experience.
Your data and integrations are still part of your current version, but because you put Enterspeed in as a Speed Layer, your frontend only runs on the data served out of Enterspeed. Since Enterspeed stores all data from your current system, you can start disconnecting sources without users noticing. The use of Enterspeed also offers the advantage that your site gets a higher Performance (fast load time) and thus a better user experience.👇
2: Decouple additional sources from your current solution
Enter: Enterspeed 🦸
Now your architecture has been slightly disassembled, and you can add your other data sources directly to Enterspeed instead of your current CMS installation.
When using Enterspeed as a Speed Layer, you can move your data sources out of Sitecore 8 and integrate them into Enterspeed instead. This in turn makes your Sitecore 8 much less complex, and because Enterspeed also stores your data, you eliminate the risk associated with live upgrading your data sources.
After this, your architecture is limited in complexity and scope, and you’re in a far better position to identify and execute what should happen to your CMS.👇
3: Keep or change your CMS
Choose with your head. And your heart 💙
It's time to upgrade to a newer CMS version such as Sitecore 10 or Umbraco 10 – or to switch to another CMS. In any case, your starting point is now far less vulnerable and complex than before.
You’ve already separated both your frontend and your data sources from Sitecore 8 or Umbraco 7, so they’re not in risk of being affected by the update.
You implement all upgrades and new integrations in the backend, and you’re not pushing anything up to the frontend until it has been tested and reported ready. The presentation layer only reaches down into Enterspeed, which has saved and draws on your "old" data until the new ones are ready. Only when the ready-made data sources are fully integrated in Enterspeed, do you close the "old" integrations.
In other words, you run both solutions in parallel and only change when the upgraded version is 100% tested. If surprises occur, it's easy to switch back to the old version.
Because you can upgrade the individual systems separately and hidden from the frontend, you have removed a huge amount of complexity, just as you have given yourself the freedom to choose exactly the CMS that best matches your needs. It also means that your upgrade will be very "standard", and it will be much easier to keep up with the upgrades that will no doubt keep coming.👇
Simpler, easier, and faster
– for your developers too
Thus, Enterspeed makes your architecture much more flexible and simple. Because your data sources are divided, and because your frontend only needs one API, your frontend developers become far less dependent on the backend developers who in turn are freed up to develop the solution rather than service the frontend.
The architecture itself also becomes less heavy and thus faster because each load only reaches down into Enterspeed, and not down into each individual data source. An important detail here is that you also get a better documented setup, as you’re not still operating a "Blackbox", where only very few know what is really happening inside. Using a decoupled setup with Enterspeed, the different sources are separated, and the different data transfers become very clear in the documentation. Of course, it also provides less vulnerability in the long run.
In addition, there will be ample opportunity to look for savings on both hosting and licensing costs. For Sitecore users in particular, it will be possible to save license fees on hosting servers that contain the sites displayed, as well as the associated licenses for the Content Delivery Servers. There is a lot to save if you have a large and complex setup around your installation today. It is also worth noting here that you have the option of switching CMS to a less license-heavy setup. Here, however, you need to be aware of the effects on the established processes and training of staff.
POC of CMS migration ✔️
Who wants to spend hundreds of hours migrating CMSs? Not us.
A migrator transferring structure and content from one CMS to another in just one minute might sound a little too good to be true.
Spoiler alert: It’s not!
There are lots of "ifs" and “maybes” of course, but as you can see in the POC video below, our migrator extension successfully migrated an Umbraco V7 to an Umbraco V10 solution in 60 seconds 🚀
In Enterspeed's Speed Layer we have a lot of data output control. Once your data from the old CMS is pushed to Enterspeed, it’s decoupled from the CMS and ready to be transformed in any way you need it.
The migrator extension consists of two elements between Enterspeed’s Speed Layer and the new data source. The first element is generic and independent from the source systems.
The other element is a CMS specific plug-in. The one showcased in the POC is for Umbraco, but we can do the same for Sitecore or any other CMS, really 💪 That means, that you can move between CMSs as well.
Also, don't forget to peek in the code if you're into that kind of thing 🧑💻👉 https://github.com/enterspeedhq/enterspeed-migrator
You see? 👀
There really is a better route
The road to upgrading a site can be expensive and complex with very little benefit at the end of the journey. However, there is an alternative route, as described above, that provides better user experiences, less risk and ensures a more long-term, durable, and flexible structure.
This structure then provides opportunities to recover savings and create new user experiences much simpler, cheaper, and easier than before. The benefits are many, and we are happy to have a meeting about what such a journey might look like for you.
If you want to migrate out of a CMS going EOL (and you should), consider using a migrator to remove a major part of the complexity. Here's a little something about our Migrator Extension.