Recovering three months of unrecoverable ERP data

Context

I spent four years at TOTVS, Latin America’s largest ERP provider — the last three as ERP Consultant, leading end-to-end implementations across manufacturing, supply chain, procurement and cost management for clients in Colombia and Ecuador.

In September 2023, a ransomware attack hit a shared cloud environment and took down access for several companies — one of them this client. Three months of inventory and billing records were gone from the ERP. The only plan on the table was manual re-entry from the last backup: weeks of retyping numbers into a system that already had the operation stalled.

The constraint

There was no clean backup that predated the attack and postdated the last good state — not for the ERP. Manual re-entry from paper was the fallback everyone else was already working. Anything faster had to come from a source the attack hadn’t reached.

What I did

I knew one thing the rest of the recovery plan didn’t account for: the BI platform I managed for that client synced daily from their ERP, and it lived on a separate server the attack never touched.

• Confirmed the BI database was intact. It wasn’t a backup of the ERP — it was an independent daily sync, isolated on infrastructure the ransomware hadn’t reached.
• Pulled the data out with MAQL and SQL while the rest of the team worked the manual path, extracting the three missing months from the BI side instead of waiting on a database that was still compromised.
• Loaded it back into the ERP with ADVPL scripts — TOTVS’s own scripting language, including scripts in a dialect that wasn’t mine, working alongside teammates who knew it better than I did — so the restoration went through the ERP’s own logic rather than around it.
• Validated against the client’s own totals before declaring anything recovered.

Results

• 100% of three months of inventory and billing records recovered, validated against the client’s own figures.
• No manual reconstruction — the quarter closed on real data.

The rest of the four years

• Full data migration for three companies inside one sugar mill in Ecuador — procurement, inventory, costs and accounting master catalogs. Three legal entities, one operation, three sets of assumptions about what a “product” is.
• A knowledge-transfer framework built on video documentation and case studies. I made it for myself because I was tired of re-explaining the same implementation decisions. The team adopted it to accelerate later projects — the same pattern that would repeat years later at MedStar.
• Process models in BPMN, and the manual the training ran on. On every implementation I ran, I modeled the client’s AS-IS and TO-BE processes in BPMN using Bizagi, as the project’s formal process-diagram deliverable — and on all but one of them I wrote the operations manual that the user training was then delivered from.
• Cross-functional user training and integration testing across multiple industries and client teams, in-situ at production sites.

What I’d do differently

• I’d have documented the recovery as it happened. I reconstructed the method afterwards for the knowledge-transfer framework, and lost detail doing it. Writing while working is slower in the moment and faster overall — a lesson I now apply by default.
• I’d push harder on the root cause. We recovered the quarter, but I spent less time than I should have on why the ERP’s own backups weren’t enough to absorb the attack in the first place, which meant the same exposure was still there the following month.
• I’d involve the client’s own team in the recovery. Doing it for them was faster. Doing it with them would have left capability behind, which is the thing I actually care about now.

Stack

MAQL · SQL · ADVPL · TOTVS ERP (MRP, supply chain, procurement, costs, quality) · BPMN modeling (Bizagi) · Excel · Power Query · Agile / Scrum