Our mission at Planet Argon is to fight the big rewrite. There are a few scenarios when we believe a complete rewrite in a new technical stack is a good business decision. Yet, we have helped many organizations migrate from their custom Ruby on Rails applications to a new platform.
Priorities shift, and business models change. Often, it's either a migration to a SaaS that didn't exist earlier in their business lifecycle or some scenarios, clients decide it is time to sunset their application. Some of our clients reach out because they can no longer access reliable Ruby on Rails developers to assist them with a decommission.
We recently had a client who had announced to their internal engineering team that they would sunset their app in about six months; nearly all of their engineers decided to get new jobs before the scheduled sunset.
When this happens, organizations will reach out to us to ask if we can a) keep the lights on for the next few months and then b) help decommission their application.
If your organization has decided to sunset your Rails app, here are recommended steps.
Step 1: Assess Your Rails Application
Depending on your technical experience, you should take inventory of your Rails apps and dependencies. Suppose there isn't already documentation that addresses this. In that case, you will need to gather info about your deployment infrastructure, the third-party services you're integrated with, how your data is being stored, and who has management access to everything.
For example, does your Rails app use AWS S3 buckets for assets? Are there any business intelligence tools that rely on a connection directly to your app's database?
Does your application expose its API to internal or external partners? What domain(s) will be impacted by this?
Step 2: Build a Comprehensive Plan
Once you understand what you need to account for, we encourage you to develop a plan to decommission your app.
While you could start from the very next steps to take, we recommend beginning further in the future.
Ask yourselves, "What does success look like six months after sunsetting your application?"
You might have goals such as:
- Customers will not ask us where our Rails app went.
- Our SEO will not be impacted; we will have zero broken links from our old URLs. People will be redirected gracefully to new tools, and it will be clear why the links no longer work.
- We will no longer be giving the Amazon Web Services overlords money to host anything related to our application.
- We will not need to write custom SQL queries to pull data from the old Rails database for several months.
...you get the idea. Now the question is, how do you get to this ideal future?
Are you going to migrate to a new platform? How much of your existing data needs to come along for the ride? Do you have customer data that needs to be transitioned? Will your new platform require you to force all users to set up a new account or login credentials?
Rarely is an application able to be entirely shut down all at once. We encourage you to consider decommissioning individual areas of an application in multiple stages. Can you shut down an API early on? Can you shut down a customer-facing area of the application while leaving a backend admin tool around for reporting purposes?
(It's never too late to introduce feature flags!)
Recently, we had a large client who migrated ~90% of their application to a new platform but had one feature that couldn't be built in the near future. We opted to lockdown everything but that one feature for them so that they could continue to use that functionality while their platform team evaluated alternatives.
Migrating the whole enchilada at once might sound ideal, but it could also slow things down drastically. Piece-by-piece is reasonable and something we strongly recommend you consider.
What communication must be made with your existing stakeholders and users? Do they need to take any action ahead of time? Will your users need tools/features built to export their data? Do you have to account for any regulatory requirements?
There are a lot of questions to be sorted out. Who are the decision-makers? As you build your comprehensive plan, we encourage you to start a timeline, a breakdown of milestones with tasks, and clearly defined roles for everyone involved.
Deciding to sunset an application is complex. It's even more important to have someone who will make the tough calls on what needs to be retained. It can be tempting to want to "archive everything" so you can undo this one day...but let's be honest, once you begin shutting a few things down, there is no turning back.
Your organization should not hoard everything forever.
Step 3: Back Up Your Data
Do you have automated backups? Excellent, maybe nothing needs to happen here. ...but how long has it been since you double-checked that those backups are legit? When was the last time you tried to run through a recovery process? You might do that before you get too far down your decommissioning process.
You'll want to be confident that you can step back at any point.
Again, are there any regulatory or compliance requirements for how you store your data? You don't want random database snapshots floating around somewhere it doesn't belong.
Step 4: Build, Test, and Re-Test Your Migration Tools
It might sound weird, but one of the fun parts about helping our clients sunset an application is that we often get to write quite a bit of code to make this happen. Do we need to build custom data exports for a migration and/or import into a new platform? Do we need to create some custom reports in SQL? Do we need to integrate with a new platform's API and begin to push data across from the systems?
While having a collection of random scripts floating around might be tempting, we encourage you to do that work in version control just as you would with any other software project. You may have to run and re-run some of these scripts multiple times.
For example, you can write scripts to pull together application data and push it across. Rather than attempt to push everything at all at once, we encourage you to test on a small subset of data and verify it's getting over to the other system the way you hope.
Often, it's easiest to do this work, ironically, within the same Rails app codebase that you're about to sunset. Add new data columns to track if records have been migrated or not. If your migration tasks fail somewhere mid-way, you can figure out how to resume vs. needing to start from scratch again. This has the added benefit of allowing you to run the same tasks, in parallel, across different subsets of your data. This can speed things up drastically!
Create some rake tasks so you can interact with your existing ActiveRecord associations. You don't have to do everything in raw SQL.
Honor your soon-to-be-dead Rails app by letting it play a role in its own death.
Step 5: Securely Delete Your Data
Once you've worked through data migrations, you will want to find a way to securely delete data that should no longer exist within your organization's infrastructure.
Are there logs that need to be wiped out, too? Delete all the things! Do you need to delete data in other third-party services? Do you have API keys floating around that no longer need to exist? Revoke and delete everything that should no longer be accessible.
Seriously, delete it. If your plan encourages you to wait several months--just in case--fine, but have the instructions clearly documented for what needs to happen and by whom. If that person leaves between now and then, is there someone else this should get assigned to?
You don't want this liability hanging over you.
Step 6: Track Your Decommissioning Progress
As your team works through your documented process, tracking progress is essential. We encourage you to keep a running list of open issues as they arise so that you can revisit and outline possible solutions/workarounds.
You'll want to keep communication channels open if things are ahead or behind schedule. This will help you keep your stakeholders and users updated, too. How will people reach out if something unexpected happens?
In many ways, decommissioning a Ruby on Rails application is very similar to launching a new one. It's likely to be bumpy, and your organization might second-guess its decision and opt to delay it should priorities shift.
I discuss the decommissioning process with Brittany Martin, host of The Ruby on Rails Podcast if you'd like to give it a listen.
A good sunsetting plan will allow your organization to hit pause and delegate it to a future version of your team.