Priority ERP Implementation: The Stages, What It Demands and Where It Stalls

A Priority ERP implementation is a project that moves a business onto Priority in eight stages: choosing the partner, characterisation, configuration and customisation, data migration, interfaces through the REST API, testing and training, go-live, and the first month-end close. It moves at the speed you make decisions and run tests, not the speed the partner works.

That single fact explains why similar projects take very different amounts of time. The stages every system implementation shares - CRM, ERP or monday - are covered in the guide to implementing a business system. This page covers what is specific to Priority: how customisation works in it, how data gets loaded, and what the interfaces need.

Who does what, and how do you choose the partner?

Priority is sold and implemented largely through implementation partners, so in practice you work with the partner far more than with the software vendor. The vendor supplies the product, the partner performs configuration and customisation, and you supply the decisions and the people.

The third row is the least measured and causes the most delay. Three questions separate partners: have they implemented in your sector - not to know the product but to know the exceptions; who actually attends the meetings - the person who sold or the person who will deliver; and how they answer an out-of-scope request - a good answer prices it separately and says what it defers. Ask for two existing customers too, and ask them one thing: what surprised you after go-live.

What are the stages of a Priority implementation?

1. Partner selection. Sector experience, the delivery team, and how scope changes are handled.
2. Characterisation. Map the current processes, decide what changes, and write a gaps list. Every gap ends up as either configuration or customisation, so everything downstream is set here.
3. Configuration and customisation. Company structure, items, permissions and documents are set up in standard screens; what those screens cannot do becomes development.
4. Data migration. Customers, items and open balances are cleaned, mapped and loaded from the old system - more than once.
5. Interfaces. Connections to the website, the store, the CRM and anything else that stays alive.
6. Acceptance testing and training. You run real end-to-end processes, not the partner, and training goes by role.
7. Go-live. Opening balances, the old system frozen, close support for the first days.
8. The first month-end close. The first time a full month runs through Priority and has to match the books.

Stage 6 is the one skipped when the date is under pressure, and it always resurfaces in stage 8 at a much higher price.

Configuration or customisation: what is the difference in Priority?

Configuration in Priority means setting the system up through its standard screens. Customisation means new development - tables, forms, reports, procedures and triggers - written with Priority's SDK. The difference matters because Priority's own customisation rules impose a process that configuration does not:

• Three installations. The SDK calls for a development environment, a test environment and production, and warns never to customise directly on the production server.
• Version revisions. A customisation moves between installations as a revision grouped in the Version Revisions form, from which the Prepare Upgrade program produces a shell file.
• A four-letter prefix. New custom entities must start with a four-letter prefix (the SDK's example is XXXX_CUSTOMERS), shared by everything built for the same customer. Ask your partner which prefix is yours: it is how you tell what in your system is custom.
• No direct writes to standard tables. The rules forbid inserting or updating standard tables directly; data has to go through interfaces that work with the form.

Every customisation is code someone has to maintain. For each gap on the list, the question to ask before approving development is whether a standard screen can already do it.

How does data move from the old system into Priority?

Data usually enters Priority through two SDK tools used together: a table load (the DBLOAD program), which imports a tab-delimited text file into an interim table, and a form load (the INTERFACE program), which moves the records from there into the real form. Excel files are converted to tab-delimited text first, and the interim data can be viewed and corrected in a form before the final load.

A form load simulates a user entering the data, so it fires the form's triggers: a record that would be rejected on screen is rejected by the load, and the interface reports which lines loaded and which failed. In practice that means:

• Clean before loading. Duplicate items and free-text descriptions fail the load or, worse, load as they are.
• Run a trial load on the test installation. It reveals mandatory fields and validations nobody listed.
• Decide what history migrates. Usually open documents and balances; full history stays readable in the old system.
• Reconcile counts and totals after every load, against the export from the old system.

Interfaces: connecting the systems that stay through the REST API

Priority's REST API is based on OData, and an interface can only reach a form that the Priority administrator has enabled in the API Forms form; sub-levels come with their upper-level form. Applications registered with Priority Software also send X-App-Id and X-App-Key headers, and requests without them are treated as generic API licensing - a licensing question to settle with the partner before development starts. The details of building on it are in the field guide to the Priority API.

For events that should leave Priority the moment they happen, a BPM rule can call a webhook, which requires the Webhooks module licence (see Priority webhooks and triggers). The most common request of this kind is a WhatsApp update to the customer when a shipping document is created. It needs a middleware service between Priority and Meta, never a direct connection, as described in sending WhatsApp updates from Priority. Plan every interface during characterisation: each one needs a test installation and its own API user.

Where do Priority implementations stall?

• Data. An item list with duplicates and free-text descriptions is a month of work nobody scheduled.
• An unagreed process. Two managers describe the same process differently and configuration halts until someone decides.
• Testing. "We don't have time to test" is the sentence that produces the hard month after go-live.
• Scope creep. Every small request looks reasonable; twenty of them are a second project.
• One person who knows everything and takes leave at exactly the wrong moment.

A well-run project shows three signs you can see without understanding the system: a current decisions log with a date and a name on every decision, an open-gaps list that shrinks week over week, and tests run by people from the business who record what failed. When one is missing, everything is "in progress", nothing is done, and the date slips a week every week.

Go-live and the first month-end close

Go-live is decided by five conditions you can tick, not by the date:

1. A full sales process runs end to end on real data, including the document and the collection.
2. Opening balances are reconciled and agreed with bookkeeping.
3. Every live interface has been tested in both directions, including a failure case.
4. Every role has a screen they can work in without asking.
5. There is a written procedure for what to do when something breaks on day one, and someone available.

The first month-end close is the real exam of a Priority implementation, because it is the first time sales, purchasing, inventory and receipts all meet the books. Before closing it, compare the trial balance with the old system's closing balances, check inventory quantities against a count, confirm customer and supplier balances, and make sure the reports your accountant needs come out of Priority rather than a side spreadsheet. Work slowing down in the first month is normal. Documents created manually outside the system, a new side spreadsheet, or a process people route around are not: each means the configuration missed something real, and it is cheaper to fix in the first fortnight than next quarter.

What to prepare before the project starts

Most of this preparation costs nothing and shortens the project more than anything else. Two weeks before the first meeting, these should be on the table:

• A list of your processes, in your names rather than the system's names.
• A list of the systems that stay alive, with a named contact for each.
• An export of customers and items exactly as they are today, dirty or not.
• The five reports management genuinely opens.
• A list of the exceptions - the customer on different terms, the item priced differently, the order that takes a special route.

On the people side you need one project owner with authority to decide between departments, a subject expert per area - finance, inventory, sales - who is available for questions, someone to clean the data, and testers with time in the calendar rather than "when we get a chance". The exceptions list is the surprise: a partner who receives it at the start designs around it, and one who discovers it the week before go-live produces urgent, expensive customisations.

Sources

• Priority SDK - Customization Rules and Best Practices
• Priority SDK - Interfaces (form loads and table loads)
• Priority REST API documentation