For the last 15 years, I’ve been part of teams that either focus on or maintain legacy software. I’ve been a part of teams that have had their legacy teams slow down the pace of innovation and get in the way of delighting our customers. However, I’ve also been a part of a team that managed their technical debt and continually evolved the product to maintain market competitiveness. Both of those projects were monoliths with major annual releases with patches to support it throughout the year. However, what happens with legacy software at a SaaS company?
At SPS, one of our leading values is to put our customers first. We look towards innovating to improve our customers’ lives by making it easier to interact with their EDI transactions or other aspects of their supply chain. How we got to our leading position today was not by accident. We accomplished it by focusing on what was painful for our customers and engineering teams and making those aspects as painless as possible. Painless is easier said than done, though, and sometimes projects that ‘just worked’ slip through the cracks.
When I joined SPS over two years ago, my team took over one of those projects that slipped through the cracks. As we set out to create a new product, Fulfillment Monitor, we built it to provide our users with greater visibility into how their data is flowing through SPS. Part of this new tool’s functions is also to provide periodic reports based on this data flow. However, SPS already had a reporting solution in place, Daily Reports. SPS created Daily Reports over ten years ago, and most of the folks that worked on it have since moved on. Daily Reports were reliable, provided high value for our customers, and were highly customizable. However, Daily Reports has not necessarily kept up its evolutionary pace with the rest of SPS technology; it was decided to replace the service entirely.
Building the replacement service was easy enough. We worked closely with a partner team building out an ElasticSearch cluster that would allow us to query for transactions quickly. Additionally, as SPS evolved, we’ve created micro-services or, at a minimum, broke up monoliths into small, more manageable services. The Monitor team was able to take advantage of these services to build out a customer-facing UI and a scheduling backend service.
While the Daily Reports replacement had benefited from SPS’s continued evolution, migrating users from the legacy service to Fulfillment Monitor’s new capabilities proved to be the more challenging part of this project; here were some of the challenges we faced:
- The original Daily Reports were highly customizable, and over a decade, had grown far beyond a set of standard reports. We could not find a programmatic path to migrate users’ reports from the old system to the new system.
- The original Daily Reports offered no user self-service features. When the new reporting capabilities went live, there was no clear path to disable an organization’s previous reporting. We suspect that our customer support teams would become overwhelmed with requests to disable the legacy reports.
- Internal users had started to use the legacy reporting service; those use cases may not be 100% supported by the replacement in Fulfillment Monitor.
There was a partnership between many teams within SPS to have a rollout that didn’t confuse our customers or overwhelm our support teams. This was arguably the most complex part of getting this capability out the door. It required the coordination of teams, careful customer communication, and manual data analysis. We have begun to roll our new reporting capabilities out. Based on this experience, here are the lessons I took away when it comes to managing legacy software in a SaaS organization:
- Sofware shouldn’t exist forever - When building new services, create plans for that service to be responsibly migrated away from or shut down over time. Any new service needs to have its lifecycle thought out before going into production.
- Never stop refactoring and decomposing - Massive shout out to my SPS peers for their dedication to decomposing their monolithic services into more manageable services. This has made it easier to extend our capabilities with the work being done by multiple teams across SPS.
- Everything has a cost - The original Daily Reports service provided immense value to our customers and wasn’t consuming a lot of time for maintenance. There are costs with doing something and also costs with not doing something. By not working on Daily Reports earlier, we focused our attention on other, more critical areas.
In closing, if you are operating within your organization’s values and have a clear vision for what your customers need, some things may slip through the cracks. Step back and evaluate the cost of taking action versus not taking action. You may find that you can tolerate some legacy services while building out the marvelous next thing. However, that next thing should have an associated life cycle plan.
Hopefully, you found this helpful!
