Content management systems (CMSes) come and go, and there are occasions when you, as a business or other organisation, has to consider migrating from one to another.
Hopefully, this shouldn’t be a regular occurrence, but it is something that most website owners will have to go through every now and again. Here are some of the most important things to consider when changing CMS.
Is your CMS on the decline?
All CMS platforms have a launch, a peak and a decline, over which time support, community and development will also peak and fall.
Right now, it’s hard to say something as gargantuan as WordPress will decline, but it’s not impossible, as there could always be a better one around the corner, or something disastrous could happen to the platform like a major security breach (we hasten to add that we see no such evidence for either happening!).
But you’ll know when yours is dropping when support queries take longer, the frequency of new plugins slows down or the interface becomes outdated. It might then be time to change.
Is the proposed one very new?
Conversely, a new CMS might come along that’s hyped as the best thing ever, and you might believe the buzz.
Of course, it might well be true, but prudent site owners will give it a year or so to bed in and overcome teething problems. Keep abreast of industry news and listen to knowledgeable people.
Is there a better alternative?
You might simply be unhappy with your current CMS and reckon a migration would be better sooner than later.
You should study deeply to ensure you’re making the right decision, however. Sometimes it’s better to have a stable presence that does 95% of what you want rather than gamble on a new one that promises 100%.
Can the same benefits be achieved with plugins and extensions?
Do you actually need to migrate? For example, if you’re on WordPress and want to add eCommerce to your offering, could you just add WooCommerce, or perhaps you’re convinced that Magento would work better? You might be surprised.
Are you prepared for any disruption?
Any migration will cause some disruption, no matter how well you plan it on staging sites. There will always be some overlooked issue, something even the most thorough migration team didn’t test, or an issue with your server or host.
That’s why it’s usually best to do migrations in the middle of the night, or whenever your demand is lowest, and to have a team of testers on hand ready to identify snags, and developers ready to fix them.
How will it affect the makeup of your team?
If you’ve got staff dedicated to one platform, do you need to retrain them in the new one or should you send them on their way and replace them with new specialists?
It’s a very tough call, as the devs themselves might not want to stick around and a good team could be broken up, but if you do a lot of your own development and support in-house, it’s a decision you’ll have to make.
What will it cost?
Finally, migrations can be expensive thanks to the number of hours it takes to do them, and also because of the new technologies, plugins, themes and extensions you’ll have to buy and services to subscribe to.
It may turn out that the benefits of migration will be only marginal compared to these one-off and ongoing costs, and that could make you question the effectiveness, given all the other risks.
You can of course keep costs low by hiring a developer to manage the migration for you rather than hiring an in-house team, but it will be on a case-by-case basis.
