ERP Integration in New Zealand

Find out what you are actually integrating with

Put these four facts in your brief and every quote you receive will be sharper:

1. Which ERP, and which version. "We're on MYOB" covers several products with entirely different capabilities.
2. Where it runs. Vendor-hosted, your own server, or a virtual machine somebody set up in 2016.
3. Whether it has a supported API. Ask your ERP partner directly; they will know, and they may charge for it.
4. Who supports it. There is usually an ERP partner or reseller, and they will need to be in the conversation whether or not they do the work.

That last point saves real money. Some ERP vendors charge for API access or require an integration licence, and finding that out during quoting is much better than finding it out in week three.

How you write matters more than how you read

Reading from an ERP is usually straightforward. Writing is where projects go wrong.

An ERP is not a database with a user interface bolted on. Creating an order triggers stock allocation, pricing rules, credit checks, tax logic and general ledger entries. A write that goes straight into the tables skips all of that and produces rows the ERP itself regards as invalid — discovered weeks later, usually by an accountant.

Acceptable ways to write, roughly in order of preference:

• The vendor's supported API or web services.
• The ERP's own import or integration module.
• Staging tables the ERP is designed to consume.
• File exchange on a schedule, where nothing better exists.

Direct writes into live ERP tables belong at the bottom of that list and usually off it. Ask each developer how they intend to write, and treat relaxed answers as a warning.

Do not let the website ask the ERP for everything

The most common performance mistake is a shop that queries the ERP for live stock on every product view. It works during testing with three visitors and falls over on a busy Monday, and the people it hurts first are the staff trying to do their jobs inside the ERP.

A sensible design decides, for each piece of data, how fresh it truly needs to be:

• Stock levels — cached and refreshed every few minutes for most businesses. Live only at checkout, if at all.
• Pricing — synced on a schedule; it changes rarely.
• Customer-specific pricing — cached per customer, refreshed when their record changes.
• Order placement — queued, so a slow ERP never blocks a checkout.
• Order history and statements — read on demand, and worth a loading spinner.

Ask what load the integration adds and how that will be tested before go-live. "We'll see how it goes" is not a plan for the system your business runs on.

Build a layer, not a web of connections

Once three or four systems need ERP data, point-to-point connections become unmanageable — each one has its own logins, its own retry logic, its own idea of what a customer is, and no two fail the same way.

A middleware layer costs more at the start and pays back on the second integration. It gives you one place where credentials live, one queue, one retry policy, one log, and one screen showing what has failed.

If the current project is your first integration and you know two more are coming, say so while quoting. It changes what a good developer proposes.

Month-end is a real constraint

ERPs get locked, batched and closed. Ask your finance team what happens in the last two days of the month and the first two of the next, then make sure the integration behaves during those windows.

Practically, that means the integration queues work when the ERP is unavailable, retries with backoff, never loses an order, and never creates a duplicate on retry. It also means nobody schedules a heavy sync for 8am on the first.

Integrate before you consider replacing

Replacing an ERP is a multi-year programme with a genuinely poor success rate and a habit of consuming the attention of everyone senior in the business. A good integration layer often buys another five years for a fraction of the cost.

Replacement becomes the honest answer when the vendor has ended support, when every new requirement is a workaround on a workaround, or when the business has changed so much that the ERP no longer describes it. Ask each developer where they think you sit, and be interested in anyone willing to tell you the ERP is fine.

Comparing five quotes

Read for:

• Who asked which ERP, which version, and where it is hosted?
• Who asked how they are allowed to write, rather than assuming?
• Who raised load and caching before you did?
• Who has integrated your specific ERP, and can name the project?
• Whose quote includes monitoring, retries and a failure screen?

Describe the ERP and version, what needs to flow which way, roughly how many orders and SKUs you handle, and who supports the ERP today. Developers who have done this before will ask about month-end before they ask about the website.