The job you keep putting off in case touching it breaks something
Framework Security Updates
We move an outdated framework up to a version that still gets security patches
The further a version falls behind, the harder it gets to move. Doing it now costs the least it ever will.
When the vulnerability warnings keep coming but touching the code looks like it will break it
When a security patch comes out for the framework you use, the version has to move up. But if you are several versions behind, things break all over the moment you try. So the job gets put off, and every month it waits makes the next attempt harder. All that time the vulnerability sits there, published for anyone to look up and still unpatched on your service.
What we do
-
First, how far behind you are
We check what version your framework and dependencies are on now, which vulnerabilities apply to them, and how many releases sit between you and the current one.
-
One version at a time, not one big jump
We don't go straight to the latest release. We move up a version at a time, so it is clear which step broke what, right when it happens.
-
Fixing what breaks
APIs that were removed, defaults that quietly changed behavior, build settings that moved: we bring each of them in line with the new version.
-
Checking it still works, then shipping it
We go through the main screens and features ourselves to confirm they work, then take it through to deploy. We don't hand back a bumped version number and call it done.
The upgrade record
Which version you came from and which one you are on now, what broke, and how we fixed it. The next time this has to be done, that record is where to start.
How to start
-
The repository and where you stand
Give us read access and we write up what version you are on and what is flagged against it.
-
Scope and timeline agreed
How far up to go and how long it takes are settled before anything starts. Nothing is charged until you agree to that.
-
The upgrade, a version at a time
We move up a version, fix what broke there, and go again.
-
Checks and handoff
We confirm it works, then hand it back together with the record of what was done.
A good fit for
- A service sitting on a years-old version of a widely used framework such as Next.js, React, or Spring
- Teams who keep seeing vulnerability warnings but put off touching the code in case it breaks
- Code whose author has left, with nobody able to move the version up
Frequently asked questions
- Do you go straight to the latest version?
- It depends on how far behind you are. If several releases sit in between, we go one at a time. Jump the whole way at once and working out what caused a break gets much harder.
- Will the screens look different afterwards?
- A framework sometimes changes its defaults or the way something is drawn. Where that happens we tell you in advance, and write up how to keep the old appearance if you want it kept.
- Which frameworks do you handle?
- Most of the frameworks in common use on the web and on the server. Tell us which one you are on and we check whether we can take it before anything else.
Start by finding out how many versions back you are
Read access to the repository is all we need to write up what version you are on and what is flagged against it.