Greentree ERP migration: choosing a destination and what it actually involves

Greentree is not broken. That is the whole problem. It is still running finance and operations, the month end still closes, and nothing is forcing a decision. Meanwhile the vendor has moved on, the partner network has thinned, and the people who understand your customisations are getting harder to reach.

Where Greentree stands

Greentree was built in New Zealand and became a genuine mid-market ERP across Australia and New Zealand, particularly in services, distribution and not-for-profit. MYOB acquired it in 2016.

Since then MYOB's mid-market investment and its sales attention have gone to MYOB Acumatica, previously called MYOB Advanced. That is the product being positioned to new customers and the one the partner channel is being trained on.

We are not going to tell you there is a published end-of-life date, because we cannot point to one. What we can describe is what customers actually report: fewer partners actively selling and supporting it, less product movement, and conversations with MYOB that steer towards Acumatica. Whether you call that end of life or simply the end of investment, the practical effect on a business planning five years ahead is similar.

Why this is not urgent, and why that is the trap

Nothing about Greentree is going to stop working next quarter. This is not a Drupal 7 situation with a dated end of support and a security exposure.

The cost of waiting is not a system failure, it is a narrowing of options:

• The people who know your customisations move on. This is the real dependency in most Greentree sites, and it has a retirement date rather than a support date.
• Partner availability shrinks. Fewer firms bidding for the work means less competitive pricing and less choice about who you hire.
• The decision eventually gets made for you. A migration you choose is a project. A migration triggered by a support event is an emergency, and emergencies cost more and produce worse results.

The four realistic destinations

MYOB Acumatica

The path of least resistance if you want full ERP capability and to stay inside MYOB. Genuine ERP depth for inventory, projects, approvals and multi-entity, and the destination MYOB itself will steer you towards. Worth weighing carefully rather than accepting by default, because "our current vendor suggested it" is not the same as "it fits best".

Microsoft Dynamics 365 Business Central

Strong fit where the business already runs on Microsoft 365, because the integration with Excel, Teams and Power BI is native rather than bolted on. The partner market in Australia is large, which matters for pricing and for not being locked to one supplier. This is the destination in our own completed Greentree migration.

NetSuite

The strongest option for genuine multi-entity and multi-currency complexity, and for businesses with consolidation requirements that turn into a monthly ordeal. Correspondingly the heaviest and most expensive of the four, so it earns its place when the complexity is real and does not when it is not.

Xero plus connected applications

The option most often dismissed too early. A meaningful number of Greentree sites use a fraction of what they are paying for: the general ledger, accounts payable, accounts receivable and a handful of reports. If that describes you, Xero with two or three connected applications for the operational side can be dramatically cheaper and easier to staff than any full ERP.

The honest test is not what Greentree can do. It is which modules your team opened last month.

How much history to migrate

The instinct is to bring everything. It is almost always the wrong instinct, and it is one of the largest avoidable costs in these projects.

What most businesses actually need in the new system:

• Open balances: debtors, creditors, general ledger, stock on hand
• Master data: customers, suppliers, items, chart of accounts, employees
• Two to three years of transactional detail for comparison and audit
• Open orders, open jobs and anything still in progress

Everything older belongs in a readable archive: the extracted Greentree data in a queryable database with a simple reporting view over it. You keep access to every record, and you do not spend the project migrating and reconciling a decade of detail nobody opens.

Reporting is what sinks these projects

Data migrates predictably. Reporting does not, and reporting is what the business judges the project on.

Greentree sites typically accumulate a large set of custom reports, and by the time a migration is considered, several things are true at once: nobody has a complete list, a good number have not been run in years, the ones that matter contain calculation logic that exists nowhere else, and the person who wrote them has left.

Do the inventory before you commit to a number. It usually shrinks the scope substantially, because most reports turn out to be dead. Our Crystal Reports inventory guide covers the method, and it applies whatever tool the reports were built in.

What goes wrong

• Customisations treated as configuration. Greentree sites are frequently customised, and the customisations encode business rules. Migrating without documenting them loses the rules and nobody notices until a process quietly stops enforcing something.
• Integrations found late. The bank feed, the payroll interface, the warehouse scanner, the ecommerce link. Each was built by somebody, and there is rarely a list.
• Chart of accounts carried across unchanged. A migration is the one realistic opportunity to tidy a chart of accounts that has been accreting codes for fifteen years. Skip it and you carry the mess forward for another fifteen.
• Cutover at the wrong time. Cut over at a period end, ideally a year end. Mid-period cutovers make comparison and reconciliation far harder than they need to be.
• Nobody assigned to reconcile. Reconciliation is finance work, not IT work. It needs a named person with the time to do it, and projects that do not allocate that person are the ones that go live on hope.

When staying on Greentree is the right answer

It is a defensible position and we would rather say so than sell a project you do not need. Staying makes sense when:

• It fits the business well and the complaints are about reporting or integration rather than the ERP itself. Both are fixable without moving.
• A larger change is coming, such as an acquisition or a restructure. Migrating twice is worse than migrating late.
• The finance team has no capacity this year. An ERP migration without finance availability fails regardless of how good the technical work is.
• The real problem is one report and one integration, in which case fix those and revisit in a year.

What is not a good reason to stay: the absence of a deadline. There is no deadline, and that is exactly why this decision drifts until somebody else makes it. The useful move is to scope the migration properly, get a real number, and then decide with the number in front of you rather than in the abstract.