Implementation

You are not starting
from a blank page.

Most software projects begin by asking you to describe everything you need. Unibuild begins by showing you a system that already runs a contracting business, then works out what is different.

Start with a demonstration → Ask for a quote

Implementation team planning a phased software rollout for a UK contractor

Why these projects fail

You have probably been
through one of these before.

The pattern is remarkably consistent, and none of the steps in it are anybody's fault individually.

Month one

You are asked to specify, in advance and in writing, exactly what you need.

Nobody has time

The answers

People describe the process they think they follow rather than the one they actually follow.

Wrong from the start

Months two to seven

A long silence. Nothing to look at, nothing to react to, nothing to correct.

Six months gone

Delivery

The system matches the specification rather than the business, so people work around it.

Shelfware

Data

History is left behind, so the business runs two systems and trusts neither of them.

Double entry

The quiet part

The administrator who built the spreadsheets was never consulted, and keeps running them.

Nothing changed

The root cause Asking a busy business to imagine software that does not exist Rather than react to one that does

What we do instead

Six things that make this a different kind of project.

Start from
working software

The platform exists and is in daily use. From the first conversation you are reacting to something real rather than trying to specify it in advance.

Configured and demonstrated in short cycles
Reviewed against how you actually work
Risk retired before you commit
The uncertainty is confined to the tailoring

The specification problem disappearsMethod

Go live
in stages

The modules that cause the most pain go first. You get the benefit of the first while the second is still being configured.

Nothing depends on one large switchover date
Value arrives before the project finishes
Adding a module later is routine, not a project
879 orders in five months proves that in practice

Phased is the normal routeMethod

Built around
your paperwork

Your certificates, reports and orders are reproduced with your branding and your layouts, so your own clients see documents they recognise.

Your logo, colours, typefaces and accreditation marks
Your terms and conditions, your clause wording
Your document numbering, continued from where you are
A design step, not a logo upload box

It becomes your systemMethod

Your data,
brought across properly

Reference data comes with you, and we advise which older records are better kept as an archive.

Clients, sites, projects, staff and training records
Asset registers, suppliers, subcontractors with expiry dates
Price lists, rate cards and open orders
Historic transactional detail usually archived, not migrated

Included in the engagementMethod

Training in
the flow of work

Office and site staff learn differently and are trained separately, on your configured system rather than a demonstration one.

Role by role, in the screens they will actually use
In a sandbox that mirrors your live database
Nothing they do while learning reaches a real record
Refreshed from live in one action when it fills up

Practise without fearMethod

The relationship
continues

Your business will change. The platform changes with it, because development is what we do rather than something that stops at go live.

The breadth exists because a real business kept asking
New modules land in running businesses routinely
Anything new you need, built inside the fee
Not a change request queue behind other clients

Why the platform is this broadMethod

The shape of it

Six stages, and most firms
live in about two weeks.

Most firms go live in about two weeks, in phases. The programme with dates on it is agreed after scoping, so the date you are given is a date we meet.

Six stages of a Unibuild implementation, from demonstration to phased go live

01
Demonstration
Your worst problem firstOn a live systemNo obligation
02
Scoping
What is differentNot what you requireAnything missing, built
03
Configure
Your rolesYour documentsYour approval routes
04
Migrate
Reference dataRegisters and expiry datesAgreed cut off
05
Train
In your sandboxRole by roleOffice and site apart
06
Go live, in phases
Worst pain firstThen the nextThen the rest

Who you need A decision maker, whoever runs operations, and the administrator with the spreadsheets That last person knows things nobody wrote down

The part nobody asks about

Your staff learn in a full
copy of your own system.

This matters far more than it sounds, and it is the
difference between a system people use fully and one they use timidly.

01What the sandbox is: A copy of your live database that training runs against. The same screens, the same permissions, the same realistic data. Nothing anyone does while learning reaches a real order, a real client, a real supplier or a real account. When it has filled up with training entries, it is refreshed from live in one action.
02Why it changes adoption: The usual reason staff avoid part of a new system is that the only place to practise is the live one. So a new administrator learns purchase order approval on real orders, timidly, and a supervisor never opens the valuation screen at all. Adoption stalls at the modules people feel safe in, and nobody can say why.
03What else it is used for: Trying a process change before adopting it. Checking a release before it reaches your live records. Showing a prospective client of your own a system full of realistic data rather than an empty one.
04One caution we will state: Refreshing a sandbox from live copies real personal data, including pay rates and absence reasons, into an environment that may have wider access. Whether your sandbox should be anonymised on refresh is a decision worth taking deliberately at implementation rather than by default, and we will raise it with you rather than wait to be asked.

Migration

What comes with you,
and what is best archived.

Everything in the first column comes across as part of the build. Paper and email in the third column can be brought in too, and we advise where an archive serves you better.

What migrates into Unibuild and what is better archived

Migrates well

Clients, sites and contactsProjects and open commercial valuesStaff records and rolesTraining and competence recordsAsset registers with serial numbersSuppliers and subcontractorsCertificates and insurances with expiry datesPrice lists and rate cardsOpen orders and retention balances

Usually better archived

Years of individual timesheet linesClosed job transactional detailHistoric invoices from your accounts packageOld certificates as scanned PDFsUnnamed photographs from a shared drive

Needs a decision first

Handwritten site diariesAnything that only exists on paper without structureEmail history from your old systemNotifications and alerts, which are events rather than data

Our advice on history

Bulk migration of a decade of unnamed images, or of every renewal certificate since 2014, is almost always more effort than it is worth. What we would migrate is the current certificate for each person and each qualification, and archive the superseded ones. The system keeps the most recent date per person per qualification automatically, so loading a renewal later does not require deleting the old one. If you genuinely need a historic archive inside the platform, say so at scoping and we will build it in rather than guess at it later.

Agreed up front

Four things we settle
before we start.

These four decide whether a rollout runs to plan, so our position on each is on the table from the beginning.

The go-live date is set after scoping

Most firms go live in about two weeks, in phases. The exact date depends on how many modules you start with and how much tailoring you need, so it is agreed once we have seen how you work. The core already exists, so the work is configuration, tailoring and migration rather than construction.

You get a sequence, not a Gantt chart

A week by week plan drawn up before anybody has seen your process is false precision, and both parties know it. Instead you get an agreed order of work, settled after discovery, with the modules that hurt most going first.

We apply your branding for you

Your branding, your document artwork, your notification recipients and your integration addresses are set up during implementation rather than left to a settings screen you drive yourself. It is one less job on your side, and it is worth knowing that is how it works.

Adoption is planned, not left to chance

It takes supervisors expecting it for the first fortnight, and the paper route closed rather than left running alongside. We plan that with you, and the platform shows the office who has submitted and whose phone has notifications switched on, so you can see it landing rather than hope it has.

Everything else on this page is how the two live deployments were actually built. Agreeing these four early is what keeps a rollout on the date we gave you.

Questions

Asked by people who are
already interested and are
looking for a reason to hesitate.

How long does implementation take?

Most firms go live in about two weeks, in phases. The exact programme depends on how many modules you start with and how much tailoring you need, so it is agreed with you after discovery. The core platform is already built, so the work is configuration, tailoring and migration rather than construction.

Do we have to move everything across at once?

No, and we would advise against it. Phased adoption is the normal route and we start with whatever is costing you the most time or money. The evidence that this works is that the purchase order module was introduced into a live deployment in February 2026 and carried 879 orders within five months. Adding a module to a running business is routine rather than disruptive, and one of the two systems has had modules added steadily for ten years without a rebuild.

Who needs to be involved from our side?

Less time than you fear, but from the right people. A decision maker, whoever runs operations, and critically the administrator who currently holds the business together with spreadsheets. That last person knows things nobody has ever written down, and they are usually the single most valuable person in the project. Any content about implementation that treats them as an obstacle has misunderstood who they are: their knowledge is what makes the configuration good.

What happens to our existing data?

Reference data comes with you: clients, sites and projects, staff records and training history, asset registers, suppliers and subcontractors with their compliance documents and expiry dates, price lists and open orders. Historic transactional detail is usually better archived than migrated, and we advise which is which at scoping.

How do our staff learn it without breaking anything?

They learn in a full copy of your own system. Unibuild can run a sandbox that mirrors your live database, so training happens on realistic data, in the same screens, with the same permissions, and nothing anyone does reaches a real order, a real client or a real account. When the sandbox has filled up with training entries, it is refreshed from live in one action.

What if we need something new?

Then we build it, inside the monthly fee. That is the business we are in, and the platform is as broad as it is precisely because a real contracting business kept asking for things and getting them. Anything new you need is built rather than left in a change request queue behind other clients.

What about a data processing agreement?

Migrating staff, client and subcontractor personal data requires a lawful basis and appropriate handling, and the processing terms should be agreed before any migration begins rather than after it. That is a prerequisite of the engagement and not a formality, and it is a conversation we would have with you at scoping. The list of third parties data can pass through is published on our integrations page so your data protection adviser can start from it.