Nobody Is Afraid of the Upgrade. They Are Afraid of What It Breaks
Businesses sit years behind on ERPNext because nobody can say what an upgrade would do to their customizations. We answer that first, on a staging copy, with a written list of what breaks, before any production date is discussed.
50+ ERP and software projects. Zero failed projects since 2021.
Staying behind gets more expensive every year
Security patches stop, community answers stop applying to your version, and each release you skip makes the eventual jump harder.
It is almost always an edit to core
Instances get stuck because somebody changed a core file rather than building a custom app, and an upgrade would wipe that change. The assessment finds every one of those edits and prices moving them into a supported app. That work unblocks this upgrade and every future one, which is where its real value sits.
- Core edits identified and listed with their purpose.
- Migration into a supported custom app costed.
- Future upgrades unblocked, not just this one.
The staging run is what makes the window real
We run the full upgrade on a copy of your live database, timing each step, so the production window is measured rather than guessed. Regression testing then puts each module through its normal cycle, and everything that breaks is fixed on staging while your live system carries on untouched.
- Full rehearsal on a copy of production data.
- Each step timed, so the window is accurate.
- Breakages found and fixed before the real run.
Everything tested before the production window
Each of these has stopped an upgrade at some point, which is why each one is checked deliberately.
From assessment to a measured production window
What the upgrade covers
Pre-upgrade assessment
Blockers, version path, and a written list of what will need work and roughly how much.
Staging rehearsal
The full upgrade run on a copy of production, with each step timed.
Regression test pack
A test per module covering your real cycles, signed off by the teams that use them.
Breakage report
Everything that failed on staging and what was done about it, before you set a date.
Rollback plan
Backup, restore steps and the cut-off point, with rollback time inside the window.
Post-upgrade support
We stay close through the first week and the first close on the new version.
What getting current gives you
Why teams choose TCB Infotech for ERPNext upgrades
ERPNext upgrade questions
We are several versions behind. Can we jump straight to the latest?
Why are we stuck in the first place?
Will our customizations survive?
How much downtime does the upgrade need?
What if something goes wrong during the upgrade?
How long does the whole process take?
Find Out Why You Are Stuck
Book a free consultation. Tell us which version you are on and what has been customized, and we will scope an assessment that gives you a real answer.
Book a Free Consultation →No commitment. A clear view of your upgrade path.
What Is Inside an ERPNext Upgrade
Running the upgrade command takes minutes. Everything that makes it safe happens before that. Here is the assessment, the rehearsal and the testing that stand behind the production window.
From finding the blocker to a window you can plan around
Why you are stuck, and the shortest safe way out
We audit the instance for core file edits, undocumented scripts and third-party apps with no maintained version for your target. Then we plan the route, which is sometimes a direct jump and often a stepped path through intermediate releases whose data patches later versions assume have already run.
- Core edits found and listed with their original purpose.
- Third-party apps checked for target version support.
- A stepped or direct path chosen on evidence.
The whole thing, on a copy, with a stopwatch
The full upgrade runs on a copy of your production database and every step is timed, which is how the production window stops being an estimate. Regression testing then puts each module through a real cycle, and print formats, integrations, permissions and key report timings are all compared against current behaviour.
- Every step timed on production-sized data.
- Module-by-module regression against real cycles.
- Print, permissions, integrations and performance all checked.
A plan that assumes something might go wrong
The production run has a full backup, timed checkpoints and an agreed cut-off after which we restore rather than push on. Rollback time sits inside the window rather than outside it, which is the difference between a controlled decision at two in the morning and an improvised one.
- Full backup verified before the window opens.
- Checkpoints with explicit go or no-go criteria.
- Restore time budgeted inside the window.
Everything the upgrade delivers
Assessment report
Blockers, version path and the work each one needs, with estimates.
Timed staging run
The full upgrade rehearsed on production-sized data, with per-step durations.
Regression test pack
Reusable tests per module, so the next upgrade starts from a known baseline.
Breakage report
What failed on staging, what was fixed, and anything you need to accept.
Rollback plan
Backup verification, restore steps and the agreed cut-off point.
Post-upgrade cover
Close support through the first week and the first period close.