Faster and Safer Are the Same Project
In an old system, slowness and security gaps have the same few causes. Fund one modernization, measure both before and after, and you pay for the foundations once.
You have been quoted twice: once to make the system faster, once to make it safer. Put the two quotes side by side and they describe the same work.
In an old system, slow and exposed usually have the same few causes: a platform that stopped getting updates years ago, no automated tests, releases done by hand, data access written the way it was in 2010, and every part able to reach every other part. Fix those once and the system gets faster and safer together.
They get quoted separately because different people raise them. Speed is an operations complaint: the screen that takes twenty seconds to load, the month-end job that runs overnight and sometimes doesn’t finish. Security is a compliance complaint: the insurer’s questionnaire, the client’s due-diligence form, the auditor’s finding. Different budgets pay for them, and different vendors sell them.
Two projects, one list
Write each up as its own proposal and you get these two lists.
What faster takes
A supported platform: years of the platform’s own speed work, inherited on day one.
Automated tests: changes ship without a week of manual checking.
An automated release pipeline: a release takes minutes instead of an evening.
Clean data access: queries the database can plan once and reuse.
Monitoring: you see the slow page before a client complains.
Smaller pieces: the busy part scales without the rest.
What safer takes
A supported platform: its security fixes start arriving again.
Automated tests: a security fix ships today instead of next quarter.
An automated release pipeline: every change is scanned before it ships.
Clean data access: no way to slip commands in through a form.
Monitoring: you see the break-in attempt as well as the slowdown.
Smaller pieces: a breach in one part stays in that part.
The first words match line for line, because the causes are the same. Buy them as two projects and you pay twice for the same foundations. More often, one project gets funded, does half the work, and leaves the other half to a vendor who starts by redoing it.
What the research says about speed and safety
The common belief is that going faster means cutting corners. Google’s DORA research program, the study behind the book Accelerate, puts it flatly: “speed and stability are not tradeoffs.” In its data, the teams that release most often also tend to have the fewest failed changes, because the practices that make release fast (small changes, automated tests, an automated pipeline) are the same practices that make it safe.
Our team has worked on both halves. At MJ Hudson, the pipeline Shan Peiris’s team built took deployments from hours to minutes (2021 to 2023). At Dealertrack Canada, Kapila works on the pipelines that carry enterprise automotive-finance applications, with security scanning and automated browser testing in them and production monitoring behind them (since 2019). One was built for speed and one for safety, and each delivers the other: a pipeline that ships in minutes ships a security fix in minutes, and one that checks every change lets you release more often.
What to ask for instead
Ask for one project with two measures on it. Before the work starts, measure how fast the slow parts are and where the system is exposed. After each piece is modernized, measure again, so you see both move.
If a vendor cannot show you both numbers before they start, they cannot show you they moved them.
Is your old system slow, exposed, or both?
Book Free Assessment