Switching rental software without a cutover weekend

Why the cutover weekend is the wrong model

Here is the plan most shops picture when they think about switching rental software: pick a Friday, export everything, spend the weekend importing, and hope the dispatch board is right on Monday morning. With 62 open bookings and gear already strapped down on trucks, that plan has no margin. One bad import and you are double-booking kit you do not have, or worse, sitting on invoices that never go out because the system that generated them just got turned off.

That fear is rational, not resistance to change. It is a correct read of the risk, and it is exactly why so many shops stay on spreadsheets and aging desktop software for years past their breaking point. The old system is slow, but at least it is wrong in ways you already know.

The fix is not a braver weekend. It is a different model entirely: run the old and new systems side by side for two to four weeks, verify as you go, and only turn the old system off when five specific numbers reconcile between the two. That playbook is the rest of this article.

How a parallel run actually works

A parallel run migration fails fast if "run both" means "enter everything twice." Nobody at the counter will do double entry for a month, and they should not have to. The whole thing rests on one ownership rule, set on day one.

Which system owns what during the overlap

From the first day of the overlap, every new quote and every new booking is created in the new system only. No exceptions, no "just this one because the client is on the phone." The old system goes read-only for new work; the only things anyone touches in it are the bookings and invoices that were already open when the overlap started. Those get worked to completion where they live.

Under this rule, nothing is entered twice as a matter of routine. Double entry becomes a verification activity — an hour once a week, owner or ops manager, comparing the two systems against each other. A check, not a daily tax on the counter staff. That distinction is the difference between a parallel run that finishes in three weeks and one that collapses in five days.

Choosing your 2-4 week window

Pick your slowest three to four consecutive weeks of the year. A fictional event and AV shop — call it Harbor Stage & Light — would run this in late January, when the corporate-event calendar is empty, not in September when every weekend has three load-outs. A plant hire yard would pick deep winter. You know your own dead zone.

Two more constraints. Do not let week one land across month-end close; you want a clean receivables baseline that does not move while you are counting it. And accept that the overlap costs one extra software bill for a month — the entire premium on the insurance policy, and cheap next to a blown weekend.

What to export: the five files that matter

Every guide to rental software migration says "migrate your data." Fine — which data? For a small-to-mid shop there are five files, and they are not equal. Stick with Harbor Stage & Light as the worked example.

Inventory and asset list

Harbor's inventory export runs 1,240 line items. About 200 are dead SKUs — cables discontinued in 2019, a fog machine that was sold, fixtures cannibalized for parts. Purge those before the import, not after; a migration is the one moment when cleaning the catalog costs nothing extra. The fields people forget: serial numbers, sub-rentable flags, and quantity-on-hand as counted, not as remembered.

Clients and contacts

Harbor has 340 client records. The trap here is contact roles: the person who approves the invoice at a production company is almost never the person standing on the loading dock. Export billing contacts and site contacts as distinct fields, or you will spend the first month of the new system emailing invoices to riggers.

Rate cards

Three rate cards at Harbor: list, a production-company tier, and a nonprofit tier. Rate cards look simple in an export and break in subtle ways on import. The fields to check by hand: weekend multipliers, weekly-rate multipliers, and any per-client overrides that were living in someone's head instead of the system. A multiplier that imports as 1.0 instead of 2.5 will not announce itself — it will just quietly underbill until someone notices.

Open bookings

Harbor has 62 open bookings with future out and in dates. These are live data, and they are the reason the parallel run exists. Each one either gets re-keyed into the new system in week one — with its deposit amount attached, not floating separately — or it stays in the old system and gets worked to completion there. Pick per booking, write the choice down, and do not split a single booking across systems.

Open invoices and deposits

Eighteen open invoices totaling $47,300, plus $9,150 in client deposits Harbor is holding. Deposits are the field everyone forgets to export, because in a lot of older systems they are a note on the booking rather than a liability with a number. Get them out as a number.

The rule of thumb, stated plainly: static data — inventory, clients, rate cards — imports once at the start and mostly stays put. Live data — open bookings and open invoices — is what the overlap window is for. And once the bookings are in, the new system should do the work spreadsheets never could: it nets availability across every quote and hold, so the 62 bookings you just keyed in immediately constrain every new quote anyone writes.

The week-by-week verification cadence

Equipment rental software implementation lives or dies on verification, and verification only happens if it is small enough to actually do. Budget one hour per week, owner or ops manager only. Here is the cadence.

Week 1: does the calendar match reality

Walk the next 14 days of the old system's booking calendar against the new one, line by line. At Harbor Stage & Light that is 23 outs in the window: same gear, same dates, same client, in both systems. Every miss is either a bad import or a booking that exists only in someone's head, and both are worth finding now, while the old system is still running and can settle the argument. This hour is boring. Do it anyway.

Week 2: quote-to-invoice on live jobs

Take three real jobs end to end in the new system: quote, confirm, dispatch, return, invoice. Then compare each invoice total to what the old rate card would have produced, to the dollar. A $40 discrepancy on a $2,100 invoice is almost never random; it is almost always a rate-card multiplier that imported wrong, and it will repeat on every similar job until fixed. This is the same failure surface described in the anatomy of a double booking — small structural errors that compound quietly. Week two is when you catch them at a cost of three invoices instead of three hundred.

Weeks 3-4: run only from the new system

The team stops opening the old system for anything except collecting on its remaining invoices. This is the honest test. If anyone still needs the old system to answer "is the 12k lumen projector free Thursday," the migration is not done — full stop. Do not force it. Extend a week. An extra week of overlap costs almost nothing; a dispatch team that half-trusts its own system costs you every day.

Five numbers that must reconcile before switching rental software off

This is the hard gate. Write these five on one page and pin it next to the dispatch board, because the gate only works if it is visible and non-negotiable. Decommission the old system only when all five match, or every gap is explained in writing.

1. Open booking count and value. Harbor started with 62 open bookings worth $118,400 in contracted value. The new system must show 62 and $118,400, less whatever legitimately closed during the overlap, with each difference named.
2. Accounts receivable, to the dollar. The old system's remaining open invoices plus the new system's AR must equal the $47,300 baseline, adjusted for payments collected during the overlap. Not roughly. To the dollar. If the receivables thread interests you, keeping rental receivables clean goes deeper.
3. Deposit liabilities. The number everyone forgets. Harbor holds $9,150 in client deposits, and a hole here does not surface at go-live — it surfaces as an angry client six months later asking for money you have no record of holding.
4. Physical inventory spot check. Count 25 random SKUs on the shelf against the new system's on-hand quantity. Accept nothing under 100 percent on serialized gear. Bulk cable stock can be approximately right; a $12,000 projector cannot.
5. The next 30 days of scheduled outs. Eyeballed one last time, by the person who actually dispatches. Not the owner, not the bookkeeper — the person who will stand in the yard at 6 a.m. and trust the board.

When all five match, the turn-off itself is an afternoon: export a final full backup of the old system to cold storage, cancel the subscription, and keep read-only archives for seven years for tax and dispute purposes. That is the whole ending. No weekend, no prayer — just five matched numbers and a canceled subscription.

See it on your own inventory

Everything above works for switching rental software of any kind — the export checklist and the reconciliation gate do not care what you are moving to. It just goes faster when the new platform is built to receive it. Ssabi onboarding follows this exact parallel-run structure: imports for inventory, clients, and rate cards; open bookings re-keyed with availability netted from day one through Ssabi Core; and a reconciliation review before you cancel anything. There is no self-serve signup, because a migration should not start with a credit card form. Bring your five export files, or just a rough count of SKUs and open bookings, and walk through your overlap window with someone who has run this before.

Request a demo