Enter a search term such as “mobile analytics” or browse our content using the filters above.
That’s not only a poor Scrabble score but we also couldn’t find any results matching
Check your spelling or try broadening your search.
Sorry about this, there is a problem with our search at the moment.
Please try again later.
Econsultancy has, in the past, provided a number of buyers' guides for digital technology.
However, I thought it would be useful to publish a brief and generic guide to replatforming, given that many companies are focusing on updating legacy technology.
Recently I read a simple guide to mitigating the risk of system migration, written by Code Computerlove, which I thought was good enough to summarise here.
It is applicable to anything from CRM to ecommerce.
1. Build a case across the business
Why are you changing platform? No matter which department triggers the change, most others will be affected, too.
Building out your objectives and goals for replatforming by allowing other teams to contribute to the process is vital.
2. Form a steering group
It can be difficult for departments to work together on a replatforming project if business as usual is normally a siloed affair.
Create a diverse steering group led by an enthusiastic agent of change.
The job of this group is to research and strategise, in order to evaluate how the new technology will impact on the business' platforms, performance, people and processes.
3. Benchmark performance
Revisit your objectives in order to define goals and then measure with specific KPIs and metrics.
You don't simply have to benchmark performance as a monetary figure. Benchmarks could include efficiency (some measure of time required for a desired output) or even staff retention.
4. Navigate the marketplace
There are no real shortcuts here, with plenty of platforms and implementers to choose from.
The IT team will have a large say in this choice, often having a preference for a particular framework such as PHP or .NET.
Be clear on what you want the technology to do (how complex does it need to be?) then invite the right suppliers to showcase their products.
5. Evaluate cost versus value
Open source and licensed products will be available. The licensed product is more expensive but may deliver more value, too, dependant on your requirements.
It's important not to dismiss costlier platforms that may bring in more revenue in the long term, through greater flexibility or functionality.
6. Test to ensure a positive impact
Prioritise where the business needs most support and test the impact of new technology here first.
For example, a new website build might employ A/B testing and rapid prototyping to ensure that new functionality is an improvement on the legacy.
To what degree the new functionality outperforms the old is important to know when managing stakeholder expectations.
7. Replace the most valuable parts first
Changing everything at once is risky.
'Application strangulation' is the technique of keeping old infrastructure in place and replacing it as you go, prioritising the most valuable parts.
8. De-couple your systems
If systems are too closely integrated, updating functionality can be more labour intensive and expensive that it needs to be.
Utilising multiple vendors and a looser integration should allow for systems to be swapped in and out more easily as the market changes.
This is often dubbed microservices architecture over monolithic application. Services should be scalable in isolation.
9. Think in products not projects
Projects are absolute and have an endpoint, which doesn't accurately reflect the nature of technology, which is always changing.
Product management is more cost-effective in the long run and will drive more value for the business.
10. Don't forget SEO
This is most pertinent for a website migration, obviously, but warrants a mention.
Benchmarking current success is important to ensure rankings are maintained after migration, from key terms to the long tail.