Legacy modernization brings an old system up to date in stages while people keep using it. We upgraded Autobuffy from Angular 8 to 13 in 20 days and moved Coach Catalyst from Vue 2 to Vue 3.
Reviewed by Azmat Rana, CEO & Founder · Updated
Old software rarely fails all at once. It gets slower to change, harder to hire for and riskier to deploy, until every new feature costs more than it should.
Core capability
Moving off versions that no longer get security fixes, such as AngularJS, Angular 8 or Vue 2, one tested release at a time.
Replacing the modules that cause the most bugs or slow everyone down, like Coach Catalyst’s CoffeeScript chat, while the rest keeps running.
Swapping FTP uploads, CSV imports and spreadsheets for APIs and background jobs, as Autobuffy’s inventory microservice did.
Adding server-side rendering to single-page apps that search engines struggle to read. Autobuffy gained search visibility after we added it.
Taking apps off aging servers onto managed cloud infrastructure, with automated deploys and monitoring in place first.
Project story · Autobuffy
Autobuffy is a US online store selling more than 100,000 auto parts. Its storefront ran on Angular 8, and the pages were built in the browser, which made them hard for search engines to read.
The outdated front end held back technical SEO, so the store was harder to find than it should have been. Inventory still arrived by FTP, CSV and Excel, which left stock levels depending on manual imports.
The upgrade raised search visibility, clicks and sales, and inventory is now accurate without manual work. Most modernization looks like this: a series of contained upgrades, each one shipped and checked before the next.
Read the full Autobuffy case studyWe change one part at a time and keep the system working at every step.
Assess
We read the code, the hosting and the data, and list what is outdated, what breaks most often and what blocks new features.
Plan
Each change gets a scope and a test plan. The riskiest or most expensive problems usually go first.
Upgrade
We upgrade one module, framework or data feed at a time, behind tests, and release it before starting the next.
Verify
Each release is checked against the old behavior, monitored in production and documented for your team.
The frameworks and platforms we upgrade most often, and the ones we move them to.
Angular
Vue.js
React
Next.js
Rails
.NET
Docker
PostgreSQLA full rewrite is tempting and usually the riskier option. These are the questions we ask before recommending either.
If the business rules are right and only the technology is old, upgrade the technology and keep the logic.
An old framework can be upgraded in steps. A data model that no longer fits the business may need rebuilding, starting with that part.
A rewrite means months of building in parallel. If the business cannot wait that long for new features, modernize in stages.
If the people who built it have gone, start by reading and testing it before changing anything.
If hiring, hosting or security fixes are no longer possible for the platform, rewrite one module at a time.
Old and new can run side by side while traffic moves across, so customers never notice the switch.
Live products we upgraded without taking them offline.
Projects like this one usually involve these as well.
Further reading: Moving a Xamarin app to .NET MAUI, step by step
Hire full-time developers in the stacks we use for this work.
What teams ask before they upgrade a system people depend on.
Bringing an older system up to date, whether that is its framework, hosting, data feeds or design, while the business keeps using it. It is usually done in stages rather than as one big rewrite.
It should not. We release each stage separately and test it against the old behavior first. Coach Catalyst moved from Vue 2 to Vue 3 while coaches kept using it.
Yes. We upgraded Autobuffy from Angular 8 to 13 in 20 days, and our Angular developers handle AngularJS migrations as well.
Yes. We start by reading the code and adding tests around the parts we will change, so we know what the system does before touching it.
Yes, hosting is often part of the work. We set up automated deploys and monitoring before moving traffic, then move one service at a time.
You do. Everything we build for you, including the source code and the intellectual property in it, belongs to you.
Tell us what you are running today and what keeps breaking, and we will suggest the first upgrade to make.