The hard part of replacing a PARCS is not installing the new gates. It is the vehicle that entered under the old system at nine in the morning and tries to leave under the new one at five. Every revenue gap in a migration traces back to a moment when two systems each believed they owned the same fact: this ticket, this permit, this plate, this payment.
Running old and new in parallel is the standard answer, but parallel is a design, not a state of affairs. Without rules, it just means two systems producing two answers.
Decide who owns each kind of data
General migration guidance on parallel running, which comes mostly from software and data projects rather than parking, makes the same point: parallel runs work best with a defined rule on which system wins for which fields, a contained pilot scope, and planned reconciliation effort. Translate that to a PARCS by listing your data classes and naming one owner for each at every stage.
Permits and credentials. Which system is authoritative for a monthly parker’s status on the day of cutover? If a permit is suspended in the old system after you have loaded it into the new one, the change has to propagate or be done in only one place. The simplest rule is that all permit edits happen in the old system until the cutover day for that facility, with a one-way sync outward.
Open sessions. Vehicles inside the facility when a lane switches are the central risk. A ticketed or plate-matched session started on the old system cannot be closed by a system that has never heard of it.
Transactions and settlement. Keep merchant accounts, terminals and batch settlement distinct per system during the overlap, so each day’s deposits reconcile to exactly one source. Merging them early makes variances unattributable.
Validations, rates and rules. Rate tables and validation partners are configuration, and configuration drifts. Export them once, diff the new system’s behavior against the old on identical test cases, and freeze edits to both during the comparison.
Cut over by lane and by direction, not all at once
Physical sequencing is where parking differs most from a software migration. One vendor transition guide suggests modern LPR-based installs can often be sequenced lane by lane so the garage never fully closes, but that is a vendor claim and depends on your hardware. A public example of the phased pattern: UT Southwestern published a campus PARCS replacement, with LPR cameras, badge readers, two-way audio and new gate arms, installed in phases across garages and lots starting in September 2026. A Penn State PARCS consultant solicitation from 2022 asked bidders for the same thing, a transition plan showing how each phase limits disruption, plus a data-conversion plan and lane-closure logistics.
A workable order:
- Shadow mode. The new system receives the same events as the old one, such as plate reads and transactions, but controls nothing. Compare its decisions with the old system’s. Disagreements are defects you found for free.
- One exit lane first. Exits are where revenue is collected and where a mistake is visible. Starting there tests payment, session lookup and receipts with a small blast radius. Starting with entry lanes creates sessions the old exits will not recognize.
- Matching entry lane. Once exits can close sessions from either system, move entry.
- Remaining lanes, one facility at a time.
The key constraint is that every exit must be able to resolve sessions from both systems until the last legacy session has closed. If the new exit cannot look up an old ticket, it needs a defined fallback, whether a manual override, a flat rate or a lookup into the legacy database. Pick it before the first lane moves.
Reconcile daily, with numbers that matter
During overlap, compare three figures every day for each facility: transaction count, gross revenue, and cash or settlement deposits. Define the tolerance in advance. A variance within tolerance is logged, and one outside it triggers investigation before the next lane moves. Reconciling only at month-end hides small systematic errors, such as a rate rule applied to the wrong day type, until they have accumulated.
Also watch the unglamorous counts: sessions open at day end, plates with no matching exit, and failed reads sent to manual review. A rising open-session count is often the first sign that the two systems are disagreeing about who closes what.
Write the rollback before the cutover
General cutover guidance recommends keeping the legacy path as the primary route at first, so that rollback means sending traffic back rather than changing anything for users. For a PARCS, that means leaving legacy controllers wired and licensed, not decommissioned, until the new system has passed its exit criteria.
Write triggers as numbers, not feelings. For example: revenue variance above a set percentage for the day, exit lane transaction failures above a set rate, or any outage on a lane lasting longer than a defined threshold. State who has authority to call the rollback and who physically executes it. A rollback plan that requires the vendor’s engineer to be reachable at night is not a plan.
Time-box the overlap, but with milestones rather than a date. Two systems running indefinitely means two sets of licenses, two sets of reports and two places for staff to look. Define the exit: a stated number of clean reconciliation days, zero open legacy sessions, and confirmed settlement with the final batch.
Don’t forget the people at the gate
The same vendor guide recommends announcing a change at least three weeks before anything physical happens and migrating monthly credentials cleanly; treat that figure as one vendor’s suggestion rather than a standard. The underlying point holds, though. Monthly parkers, tenants and validation partners should hear about a change from you, not from a different gate behavior on Monday. Staff need a one-page procedure for the three most likely problems: a legacy ticket at a new exit, a credential that fails, and a payment that errors.
The short version
Name one data owner per class at every stage. Shadow first, then exits, then entries. Keep payments and settlement separate until reconciliation is boring. Write rollback triggers with numbers. And do not turn off the old system until the last session it opened has closed.