Top Priority Systems adopts a "custom" approach to implementing Purplesoft. The implementation is broken into phases, but there is flexibility in each phase and indeed even in the sequences depending on customer objectives and budgets.

Kick Off

We start by creating a timetable for your implementation, taking account of your preferred go live and the people you have available for the implementation - their skillset, the time they have available and their location. This includes a division of responsibilities - for example who will be tasked with obtaining data for migration, who will convert it, who will design stationery, and who will perform user training.



During the discovery phase, we explore every detail of your existing operation, from key documents and reports to processes which are not well addressed. In a normal implementation we create a written document that maps features in Purplesoft to all your processes - in effect you end up with an implementation on paper.


We start the Build Phase by installing the software, either in the Cloud or on one of your servers. We then configure it to reflect the decisions taken during the Discovery Phase.

The first pass of data migration typically occurs at this point. Static data can be brought across from your existing systems: usually this will include customers, vendors, parts and services, price lists, vendor prices lists, bills of materials, and your Chart of Accounts.

We aim to create two separate environments: one is the live system, the other is a demo version. Both include all your data. The demo version provides a "sandbox" environment where you can test your processes without fear of making errors.


If you require tailoring, this happens at this point. We create a specification of changes that we identify as being required during the Discovery Phase. We aim to write the specification in two "languages": first in a way that is readily understood by the customer, including the purpose of the changes; and then in a way that is readily understood by the developer. Highly technical people can follow both versions.

After the customer agrees the specification, the developer writes the code. A consultant then tests it, and if necessary any bugs are sent back to the developer for fixing. Then the code is sent to the customer for acceptance testing, and again it is possible to send further changes to the developer.

Education &

During the sales process and/or during the kick-off, we agree on the methodology for training - whether we will use a train-the-trainer approach, where we train "super-users" who then go on to train your staff, or we train everyone. There are standard training materials, which can be varied to customer requirements. Training is performed in a classroom environment, on customer equipment.

You should also plan to hold user acceptance tests immediately after training. This involves each staff member going through their normal work processes, and confirming both that they understand how to perform these in the new system and that the system is working well for them.

Go Live

Immediately prior to Go Live, the main data migration is performed - for transaction data such as open receivables and payables, open sales and purchase orders, open work orders and jobs, and opening inventory. The opening Trial Balance usually takes customers a few weeks to prepare in their old system, so this follows after Go Live.

The handholding process through the initial days of Go Live is normally performed on-site, although an increasing number of implementations are 100% over the internet. We make a consultant available to your staff at this time, for two reasons:
• to repeat training, when people forget what was covered earlier
• to resolve any issues that slipped through the earlier stages of implementation.