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
Don’t laugh… it may seem obvious, but far too often, I’ve seen teams jump into a replatforming effort, and completely skip the planning phase. (I’ve done it myself, if I’m being honest.) It’s easy to fall into this trap in order to try and save some time. However, if we were to step back from the “ease” of the situation and assess the “why” of our goals, we’d quickly identify the inefficiencies, existing struggles, bad ideas, and bad practices that all lead to extra development time, which is most likely why we’re contemplating a replatforming to begin with. When we approach the replatforming effort with this mindset, it becomes crystal clear that we don’t know everything that we need inside and outside of our replatforming effort.
I begin every replatforming by answering several key questions:
1. Why are we doing this, and what problems are we trying to solve? (The real reasons, not the industry buzzword reasons.)
2. What are my 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 we respect the business and existing user needs during this process?
In other words, I know I’ll still have to get bug fixes and hot items to production in the legacy stack while managing the efforts of replatforming.
Once my questions are answered, I approach the problem the same way I approach a brand-new set of requirements. After all, this project is just like any other that I’ve done before. There’s a start, there’s a destination, and my number one job is to formulate a complete plan so I can give my team the exact directions they need to get to our destination, with no wrong turns, no detours, and no roadside emergency calls to AAA.
Manage scope creep
I really enjoy legacy replatforming efforts, because I’m usually armed with user insight that I wouldn’t have if I were developing a brand-new product. Odds are, I’ve received an earful from users, developers, and the client alike regarding the pain points of the existing application. Because of this, I tend to know exactly what I’m getting myself into.
There’s a catch, though. Once the project begins, the requirements are locked in – solid – with zero exceptions. This is the second largest trap I’ve seen so many teams fall into over the years (the first being overall lack of planning). We get a quarter of the way through, someone points out a pain point we didn’t know about – often because of poor planning – and we take it upon ourselves to remedy this pain point during the replatforming effort. First of all, had we planned accordingly, we’d already know about this pain point, and it’d be accounted for. Secondly, by taking on this initiative mid-flight, I’d be willing to bet this month’s paycheck that this “easy fix” wasn’t planned 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. We all know that person. I’ve been that guy. More than once. I have the t-shirt, and the scars. They don’t know the effort yet, so don’t trust them when they say, “it’s easy.” You’ll be let down more often than not.
Scope creep will kill a replatforming effort quicker than video killed the radio star. Because we’ve planned accordingly (hint, hint), we’ve locked our requirements in, we know the plan, and we’re going to protect the plan – and say no to new requirements – until we’re done. I make my developers and stakeholders all agree to this upfront, and I remind them of this agreement every step of the way. This replatforming effort is going to net us the architecture we need to respond more quickly to business demands and add new features quicker with lower effort; we can worry about all the “wish list” items when we’re done.
Do it in phases
Part of the planning process should include a clear strategy on how we can release our new, shiny efforts into production as we 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 we’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 we as engineers are creative problem solvers – we make the seemingly impossible possible. It’s a big ask, but I’ve never met a situation where my team and I weren’t able to find a way to make it happen. I’ve made React live with Angular, .NET play with Java, Python feed Ruby on Rails – you get the point. 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 our planning where we identified the “why” – why is this needed, why are we doing this, why is what we have currently not working for us? We need to clearly identify the pain points of our existing application and use these discoveries as an opportunity to grow from our 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 our existing code base. I’ve found, if nothing else, past decisions tell me what not to do this time around.
To be clear, I’m more focused on developer experience here. If there are any low hanging user experience pain points I can remedy without affecting my effort or deliverable, sure, why not. But, my main focus is, and will always be, developer experience as part of this process. If I can use the replatforming to improve developer experience, new features get developed quicker, bugs get resolved faster, more code gets to production, and my team has more fun along the way.
By taking inventory of the existing pain points in areas such as our current architecture and infrastructure, I have a clear starting point of all the roads I definitely don’t want to travel down. Examining the “why” behind each point will help to guide my decision-making process moving forward to ensure we choose the right technologies and solutions to the problems at hand.
Don’t rush it
I often meet with
stakeholders who are 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.
About the Author: