ERPNext Upgrade
Businesses sit years behind on ERPNext because nobody can say what an upgrade would do to their customizations.
Why It Matters
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.
We run the full upgrade on a copy of your live database, timing each step, so the production window is measured rather than guessed.
We find the blockers, map the version path and list what will need work.
Core edits moved into a supported custom app so upgrades become possible.
Full upgrade on a copy of production, with every step timed.
Regression testing per module, with fixes applied on staging.
A measured window with backup taken, checkpoints and a rollback point.
Blockers, version path, and a written list of what will need work and roughly how much.
The full upgrade run on a copy of production, with each step timed.
A test per module covering your real cycles, signed off by the teams that use them.
Everything that failed on staging and what was done about it, before you set a date.
Backup, restore steps and the cut-off point, with rollback time inside the window.
We stay close through the first week and the first close on the new version.
Knowing why you are stuck is more useful than a date you cannot keep.
Moving core edits into a custom app fixes every future upgrade, not just this one.
We time the staging run, so the downtime you plan is the downtime you get.
The cut-off point is agreed before we start, with restore time inside the window.
We take intermediate versions when that is safer, rather than forcing one jump.
Sometimes, but often it is safer to step through the intermediate releases, because each one carries its own data migration patches that later versions assume have already run. We work out the shortest safe path during the assessment rather than attempting the biggest jump and hoping.
Almost always because somebody edited core files instead of building a custom app, so an upgrade would overwrite work nobody can reproduce. The assessment finds those edits and tells you what it takes to move them into a supported custom app, which is what unblocks every future upgrade too.
Anything built properly in a custom app usually needs adjusting rather than rebuilding. Anything patched directly into core will be lost. We test every customization on a staging copy against the target version and give you a written list of what breaks before you commit to a date.
For most instances a few hours, usually taken overnight or at a weekend. Very large databases take longer, and we measure the actual duration during the staging rehearsal rather than estimating it, so the window you plan is the one you need.
We take a full backup before starting and agree the rollback route and its cut-off point in advance. If a checkpoint fails we restore and you are back on the previous version the same night, which is why the window includes rollback time rather than assuming success.
Typically 3 to 6 weeks from assessment to production, with the production upgrade itself being a single window. Most of the time goes on the staging rehearsal and on fixing whatever the regression testing finds, which is exactly where it should go.
Related
The other services in this section, and related pages from TCB Infotech.
No commitment. A clear view of your upgrade path.
