Free self-check
Is your old software ready to be rewritten?
One minute. Ten questions for anyone running an old CMS, a legacy platform or an internal tool nobody wants to touch. You get a score, the gaps that make a rewrite risky, and what to do about each one.
- A scoreOut of 100, with what it means for you.
- Your checklistWhat is in place, what is partly there, what is missing.
- What to doA fix for each gap, with steps to check it yourself.
- A report to shareBy email if you want it, ready to forward to your team.
Your result
0/100
Ready to modernize
You know what the system does, it is safe to change and the reasons to move are clear. Modernizing it piece by piece is low-risk from here: start with a small part and prove the path.
Ready, with gaps to close first
A rewrite could work, but some of the groundwork is missing. Each gap below is a place where a rewrite can lose a rule, break an integration or damage data. Close them first: most of that work also makes the old system safer today.
Too risky to rewrite yet
Too much of what the system does is unknown or unprotected for a rewrite to be safe. Start with the first item below: understanding and testing the old system comes before replacing it, and costs far less than a rewrite that goes wrong.
What’s next? One, two or all three.
Enter your email once, then choose.
We only send what you ask for. Privacy
Where to start
- Do you know everything the system does, from start to end?
Make an inventory: every screen, report, scheduled task, email and export, and the person or team that relies on it. What nobody remembers is what a rewrite forgets.
Read: Using AI to read legacy code: maps, documentation and business rules
- Are the business rules written down somewhere outside the code?
Write the rules down in plain words, starting with the ones that touch money or customers, and have the people who use the system confirm each one.
- Does more than one person still understand the code well enough to change it?
Pair a second person with whoever knows it best, write a short guide to how it is built and run, and record why the odd parts are the way they are.
Read: How to tell whether the AI’s code is good, without being an expert
- Do automated tests check what the system does today?
Before changing anything, write tests that record what the system does now on its most important paths. They are what tells you the new version behaves the same.
Read: Characterization tests: write down what the old system does before you change it
- Can you release a change safely, and often?
Set up a full copy of the system to test on, ship small changes one at a time, and write down how to undo each release before it goes out.
- Is your data clean, and do you know what each table and field means?
Document what each important table and field means, find the duplicates and the inconsistencies, and decide how each one gets fixed before the data moves.
- Do you have a map of every system it connects to?
List every connection: what goes in, what comes out, how often and who owns the other side. Integrations nobody remembered are where migrations break.
Read: Data contracts: agree on the shape before you connect two systems
- Is everything it runs on still supported and getting security fixes?
List each piece with its version and its end-of-support date. Anything already out of support is a security risk today, and sets the order of the work.
Read: Old software, new rules: when to rewrite, and when to leave it alone
- Is there a clear business reason to modernize, with a number attached?
Write down why it matters in numbers: what the old system costs in time, money or risk today, and what has to be true for the change to be worth it.
- Could the system be split into parts that can be replaced one at a time?
Draw the system as a handful of parts and the lines between them. Pick a small, low-risk part to move first, to prove the path before the big ones.
Read: Replace it piece by piece while it keeps running: the strangler fig pattern
No gaps on this list. Your system is in good shape to be modernized.
What’s next? One, two or all three.
Enter your email once, then choose.
We only send what you ask for. Privacy
Built from real projects
Every question comes from what we have seen go right, and wrong, on real work. See it in practice:
Affiliate Site Turnaround in 10 Weeks →Questions
- Is it really free?
- Yes. The result appears on the page, and nothing is asked of you to see it.
- What happens to my answers?
- They are scored in your browser. We only receive them if you choose to send them to an engineer or ask for the report by email. See our privacy policy.
- Will you add me to a newsletter?
- No. If you ask for the report, we send that one email. We only write again if you reply.
- Who is behind it?
- EVDevs: experienced engineers working with AI on revenue, data and AI systems. About us.
Prefer to skip the check?
Talk to an engineer, book a 15-minute call or join the newsletter. No check needed.
Prefer to write directly? enable JavaScript to see the address