When it comes to taking a big trip, one thing’s for sure – preparation is key, but flexibility is required. The same goes for platform migrations. But that doesn’t mean they need to feel like an uphill battle! To help you put your best foot forward, HM Web Engineer Rufaro Madamombe is outlining the steps that’ll keep you on-track and aiming high.
1. Determine why you’re hiking
Before attempting a hike, the best motivation is to establish why you’re hiking in the first place.
The same goes for platform migrations. Communicating the reasons behind a platform shift to your stakeholders and partners will help ensure the trail you pick is leading towards your ultimate goal, and that everyone’s aligned on the destination and outcomes to be achieved.
Here are some questions to ask yourself and your team to help determine the ‘why’:
- What are the pain points you’re currently facing with your website?
- What does success look like post migration?
Knowing where you’re going is the first step towards getting there!
2. Scout the mountain
Next, you need to understand what kind of terrain you’re dealing with – a sprained ankle is a quick way to ruin a beautiful view!
There are a number of questions you can ask to determine the size and scope of your migration:
- What’s your existing environment configuration? – CMS type and version, PHP version, Node version, MySQL version etc.
- What’s the size of the data?
- What format is the data in?
- What kind of data is stored?
- What are the relationships between the data?
- Where is the data stored?
- How will you get the data to your agency partner or suppliers?
- What plugins are in use?
- What themes are in use?
- What features need to be rebuilt as part of the migration?
- What existing features need to be mapped to WordPress core?
- How will any partners get access to existing codebase?
- How are users and roles managed?
- How is DNS currently managed?
(Note data isn’t just what’s in the database, but also any media assets.)
If you don’t have answers to all these questions yet, don’t panic – partnering with an experienced agency can help you unlock the trickier parts of a platform migration, and they can offer guidance as to where solutions can be found.
3. Choose a trail
With a good understanding of why you’re hiking and what the mountain is like, next up is choosing what trail to use. There are three potential trails to take:
- Manual – No automation to process existing data. This usually means a manual rebuild of pages or content, and code may be written for new blocks.
- Fully automated – Existing data is automatically processed into the new site, with any necessary mappings to core functionality completed or new custom blocks are created.
- Hybrid – A combination of manual and automated where some parts are fully automated and others require manual work. This usually depends on complexity of the work.
Another key factor to consider when choosing a trail is the time that you have to complete the migration.
Sometimes a fully automated migration may be technically possible, but there isn’t enough time to write all the code – in this example case a hybrid approach might be needed to finish the hike on time.
Again, if you’re unsure of which trail to pick, a trusted development partner can act as your guide.
4. Get your gear ready
Time to pack your bags! Rather than nipping to your local outdoors store, we encourage our clients to turn to open source tools to get the job done.
Fortunately, we’ve done many migrations over the years, and so we’ve created some tools you might want to consider using.
- HMCI – Useful for when you need to automatically get different data sources in WordPress.
- HM ACM – Handy for provisioning ACM SSL certs for different domains on a network.
- Mercator – Helpful for mapping different domains to a site on the network.
Depending on complexity of the project, you may need to use all those tools or come up with entirely new ones, but it’s always worth checking what’s on offer before considering custom solutions.
5. Expect obstacles
Regardless of how much you prepare and have a well though-out plan, expect obstacles. Some challenges can be planned for in advance, but a degree of flexibility is always necessary.
Some other things to be on the lookout for:
- Data integrity – It’s easy to assume that your data will be complete, but a variety of factors can be at play and sometimes it may not be! Workarounds can be found, but this may lead to the next point…
- Delays – Whether internal or external, delays are sometimes inevitable. Be sure to leave a window of ‘buffer’ time for unforeseen setbacks, particularly if you have a hard deadline for a completed migration.
- Incompatibilities – Some third-party plugins or themes may not be compatible with your new platform, so again be sure to leave extra time available for patching, replacing or removing these.
Other obstacles you’ll only encounter as the platform migration project progresses so it’s a good idea to keep a record of those obstacles and what risks they may pose to the success of the project i.e make the risk log your friend.
6. The summit
The summit is in sight!
While it’s possible to reach some mountain summits alone, it’s almost certainly less risky (and more fun!) to reach the top with other people.
In the case of platform migrations, the summit is launch day and you definitely can’t reach it or have a successful one alone: I’d never recommend anyone try to do everything themself during the project or on launch day.
Lean into the team around you, from your development squad and wider engineering stakeholders, all the way through to product, commercial and leadership teams. They can help you to brainstorm, plan, and develop solutions to obstacles so you can reach the summit, as well as plan what will actually happen on launch day.
It is definitely preferable to start the launch plan early in the project (even during your scouting/discovery phase), because some items will need some lead time – you don’t want to start planning a week before the project is set to launch.
Here are some questions to ask as you build a launch plan:
- When will UAT testing be done?
- Do you need to inform other stakeholders/customers of the launch date in advance? – This may be something that determines when launch can happen, e.g if you need 2 weeks advance notice then when that notice is given will effectively determine when launch could happen.
- When will content freeze be?
- When will code freeze be?
- When will your developers get the final database export?
- When will developers import the final database export?
- What DNS changes need to be done and when?
- When will go live be confirmed? – This is about the final decision to launch, and it may be on the same day as launch day. Note that it’s possible for some launch day tasks to fail, which could necessitate aborting the launch.
For every item, assign an owner; delivery date and time; estimated time to complete and status. It’s also a good idea to be as fine-grained as possible so that progress for a milestone can be tracked as individual tasks are completed.
7. The celebration
Reaching the summit is of course a moment for celebration and pause, but have you thought about what happens next?
While it may be exciting to focus on only the things to do to reach your goal and complete the platform migration, it’s also a good idea plan for what to do after launching. Below are a couple questions to ask:
- What post deployment checks need to be done?
- What’s the rollback plan? – In case your migration is launched unsuccessfully, and therefore a rollback to the previous site is needed.
8. Don’t forget to enjoy the view
To make sure you get back down that mountain side safely, monitor the new platform’s performance and make any necessary changes post-deployment.
Finally, it’s time to sit back and enjoy all the hard work you’ve put in. Enjoy your new platform!