Auditing what you already run

Before deciding what replaces what, list what exists. This is duller than it sounds and consistently surfaces surprises.

Inventory every system

For each one: what it does, who uses it, what it costs annually, what data it holds, what it connects to, and who owns the account. That last column is the one that causes trouble later — software nobody can log into administratively cannot be migrated or cancelled.

Include the things people do not think of as systems: the shared drive, the WhatsApp group where orders are confirmed, the accountant's own copy of the books.

Classify each one

Replace. The new system does this job properly. Most of the ERP-shaped tools land here.

Keep and integrate. It does something ERPNext does not do well, and it does it well. Specialist tools frequently belong here; replacing them with a worse built-in module to achieve "one system" is a real and common mistake.

Keep and ignore. It serves a corner of the business the project is not touching. Say so explicitly, or someone will assume it is in scope.

Retire. Nobody has used it for a year. Someone will still object. Ask them when they last opened it.

The spreadsheet question

Spreadsheets deserve their own pass, because they are where the gaps are. For each significant one, ask what it is compensating for: a report the system cannot produce, a field it does not have, an approval it does not enforce, or a calculation nobody trusts it to do.

Some of those become configuration. Some become customisation. And some are genuinely better as spreadsheets — a monthly model with assumptions that change every month does not belong in an ERP, and forcing it in is how you end up with a customisation nobody maintains.

What this produces

A migration scope, a licence-cancellation list with real numbers, and an integration list. The second one funds the project; the third one is usually underestimated by a factor of two.