Five Practical Tips for Replatforming and Sunsetting of a Legacy Application

Replatforming can be a huge and somewhat intimidating undertaking, but it doesn’t have to be. By using a realistic timeline, creating a thorough project blueprint, and having a bit of flexibility, you’ll be reaping the benefits of your new application before you know it. Here are five practical tips for your replatforming efforts:

Have a plan

It may seem obvious, but far too often, teams can jump into a replatforming effort, and completely skip the planning phase. It’s easy to fall into this trap in order to try and save some time. However, if you were to step back from the “ease” of the situation and assess the “why” of your goals, you’d quickly identify the inefficiencies, existing struggles, bad ideas, and bad practices that all lead to extra development time, which is most likely why you’re contemplating a replatforming to begin with. When you approach the replatforming effort with this mindset, it becomes crystal clear that you don’t know everything that you need inside and outside of our replatforming effort.

Before beginning any replatforming, here are several key questions to ask:

1. Why are you doing this, and what problems are you trying to solve? (The real reasons, not the industry buzzword reasons.)
2. What are our goals and desired results?
3. How will success be measured?
4. How will this effort impact existing users?
5. How will this impact existing dev team(s)?
6. How will you respect the business and existing user needs during this process?

In other words, know that you’ll still have to get bug fixes and hot items to production in the legacy stack while managing the efforts of replatforming.

Once these questions are answered, you can approach the problem the same way you approach a brand-new set of requirements. After all, this project is just like any other that you’ve done before. There’s a start, there’s a destination, and the number one job is to formulate a complete plan so you can give your team the exact directions they need to get to the destination, with no wrong turns, no detours, and no roadside emergency calls to AAA.

Manage scope creep

Legacy replatforming efforts are a little bit different, because you’re usually armed with user insight that you wouldn’t have if you were developing a brand-new product. Odds are, you’ve received an earful from users, developers, and the client alike regarding the pain points of the existing application. Because of this, you tend to know exactly what you’re getting yourself into.

There’s a catch, though. Once the project begins, the requirements are locked in – solid – with zero exceptions. This is a large trap teams can fall into. You get a quarter of the way through, someone points out a pain point you didn’t know about – often because of poor planning – and you take it upon yourself to remedy this pain point during the replatforming effort. By taking on this initiative mid-flight, this “easy fix” probably wasn’t planned for properly and will take two, three, or even four times as long as expected. Anytime you hear a developer say, “oh, that’ll be easy – sure, no problem,” don’t listen. They don’t know the effort yet, so take it with a grain of salt when they say, “it’s easy.” 

Scope creep will kill a replatforming effort quicker than video killed the radio star. Because you’ve planned accordingly, you’ve locked your requirements in, know the plan, and you’re going to protect the plan – and say no to new requirements – until you’re done. Getting your developers and stakeholders to all agree to this upfront is best, and remind them of this agreement every step of the way. This replatforming effort is going to net you the architecture you need to respond more quickly to business demands and add new features quicker with lower effort; you can worry about all the “wish list” items when you’re done. 

Do it in phases

Part of the planning process should include a clear strategy on how you can release your new, shiny efforts into production as you complete them. This means breaking down the project into chunks, and addressing any architectural needs and concerns that will allow both the legacy app and new app to coexist.  You don’t want to replatform in isolation, waiting until you’re “completely done” to release it all in one big ceremony. By releasing updates continuously everyone stays engaged, especially key stakeholders.

This won’t be an easy task, but engineers are creative problem solvers who can make the seemingly impossible possible. It’s a big ask, but where there’s a will, there’s a way – it just requires creativity.

Learn from past mistakes

We’ve all heard the quote “insanity is repeating the same mistakes and expecting different results.” One could argue that the exact same thing could be said about replatforming. Remember back in the planning phase where you identified the “why” – why is this needed, why are we doing this, why is what we have currently not working for us? You’ll need to clearly identify the pain points of your existing application, so you can use these discoveries as an opportunity to grow from your past mistakes. These pain points, of course, stem from poor decisions, poor architecture, deep coupling, poor naming conventions, and other bad practices that might have crept into the existing code base. If nothing else, past decisions tell you what not to do this time around.

If there are any low hanging user experience pain points that can be remedied without affecting your effort or deliverable, sure, why not. But, one of your main areas of focus should always be developer experience as part of this process. If you can use the replatforming to improve developer experience, new features get developed quicker, bugs get resolved faster, more code gets to production, and the development team has more fun along the way.

By taking inventory of the existing pain points in areas such as your current architecture and infrastructure, you’ll have a clear starting point of all the roads you definitely don’t want to travel down. Examining the “why” behind each point will help to guide the decision-making process moving forward to ensure you’re choosing the right technologies and solutions to the problems at hand.

Don’t rush it

Stakeholders are often hesitant to invest in replatforming because they have a hard time seeing the value in redeveloping something that is currently making money and “works just fine.” After all, they don’t know what it’s like to work in the legacy application day to day – they’re not the engineers, but once the engineering side of the house finally persuades the business side of the house to give permission for the replatforming, the stakeholders often concede by saying, “fine, but you have until [too short of a timeline] to get it done.” The project is already sunk before it’s started. Corners will be cut and poor decisions will be made, not on purpose, but because there won’t be plans in place to manage the needs of the existing product while replatforming in tandem, and your development team will end up overworked, burned out, and software entropy will start creeping in.

When planning your replatforming engagement, stakeholders and engineers alike should be realistic about the timeframe, and leave time for the unknowns, surprise production bugs, proper tooling up of new technologies, and life in general. The best way to protect any project is to keep your developers engaged, and give them enough time to set the company up for success. Only then will they be able to deliver a codebase that will support the company for years to come, engineered with continual growth in mind. 

Need Help Replatforming? Let’s Talk!