ERP rescue · Stalled projects
Stalled half‑way? We read it before we touch it.
What was loaded, what was customised and what was never finished, written down first. Then a written plan: what to keep, what to fix, what to finish and what to drop.
Sound familiar?
The project stopped, and the ERP is half there.
“Our partner walked away mid-project.” “The data arrived incomplete and was signed off anyway.” “Go-live keeps moving.”
A stalled rollout is rarely all wrong. Some of it is sound. The work is finding out which part, before anything is redone.
How a rescue runs
Read first. Decide in writing. Then finish.
01 / 05
Read what is there
Read-only access. We record what has been loaded and whether it ties to the source, what was customised, the open issues, and the previous partner’s documentation, including when there is none.
What you doYou grant read-only access. A sanitised copy is fine.
02 / 05
Decide each part
Each part is marked keep, fix, finish or drop, with the reason, in writing. Nothing is redone until it is clear what is already correct.
What you doYou review the plan and agree it.
03 / 05
Fix what is wrong
Records that do not tie to the source are corrected. Customisations that will not survive an upgrade are rebuilt to the framework’s conventions.
04 / 05
Finish what is missing
The missing parts are built and loaded in the order they depend on, and checked against the source before sign-off.
05 / 05
Take it to done
Go-live on a checked system, with the work written down so the next person can pick it up.
What you doYou sign off.
Keep, fix, finish or drop
Every part gets a decision and a reason.
Sometimes the right call is not to finish a part. The assessment says so plainly.
Keep
- Master data that ties to the source
- Settings that match how you work
- Customisations built to the framework
Fix
- Records loaded with gaps or duplicates
- Customisations that will break on upgrade
- Reports that do not reconcile
Finish
- Open orders and balances not yet loaded
- Steps that were scoped and never built
- Cutover and sign-off
Drop
- Work that no longer fits the business
- Custom code a standard feature now covers
- Scope that costs more than it returns
In writing
What you get in writing.
- A written reading of the current state
- The keep, fix, finish or drop plan, with the reason for each part
- A fixed-scope quote to finish
- The data handover pack when a partner changes
Yours to keep, whoever finishes the project.
On record
Picked up part-way, carried through go-live.
Before BI Margin, we took over half-finished ERPNext migration work, code and import process included, and carried it through go-live. The method carries to other platforms.
5+ years of hands-on software development, integration, optimisation and automation.
How a rescue is priced.
Every rescue starts with the Systems Assessment, which has one fixed price. The rescue itself is quoted in writing after it. Book a call and tell us where it stopped.
Questions
Before a rescue starts.
Rescue it or start over?
The reading decides. If most of it is sound, we keep it and finish. If it is not, the plan says so, with the reasons.
Can you work with what the last partner built?
Yes. We read it first and keep what is correct. Where there is no documentation, the reading becomes the documentation.
Our ERP is not ERPNext.
The method carries across. The delivered work behind it is on ERPNext, and the assessment confirms what we can read first on your platform.
Is our data safe while you look?
We work with read-only access. A sanitised copy is fine for the reading.
Next step