Skip to main content
Checked against the product · 2026-10-05

Cutover — the order it happens in

For: the controller who will run cutover once · Time to read: five minutes · Prerequisite: none — read this first

This guide holds almost no detail of its own, on purpose. Every step below is already documented, and documented well. What none of those guides can tell you is the running order, because each of them is about a screen and cutover is an event that crosses five of them. This is the order, and the handful of things that are true only in the seams between them.

Part 1 — Three things to get straight first​

It is not one switch, and most of it has already happened​

Long before cutover, Arcvue is already booking natively from your own feeds — bank, payroll, payables, timecards, contracts, leases. The boundary you set at cutover does not turn the product on. It changes which system is authoritative for the periods after it.

So do not expect cutover day to feel like a migration. If the platform has been doing its job during the parallel run, the day itself is quiet, and that is the intended outcome rather than a sign something was skipped.

It is per segment, not per company​

Cutover is initiated one segment at a time — a segment being a legal entity. A group with two entities cuts over twice, and the two need not happen together. Each segment carries its own boundary period and its own record of who decided it.

Nothing gates it, and that is deliberate​

Arcvue still runs its readiness checks, but they are evidence, not permission: they grant or withhold nothing, and a boundary can be recorded while checks are outstanding.

This is a decision a person makes. Arcvue's job is to keep what the checks said at the moment somebody decided, alongside the decision. If you are waiting for the product to tell you it is time, it will not.

Part 2 — The order​

Step 1 — The parallel run was the preparation, and it is over​

Where the detail lives: Parallel Run — kept for the record only. The Parallel Run screen was retired from the product on 2026-09-05; there is no page to open and nothing left to work down there.

This step is here because it is first in the order and because the preparation it describes is what everything below rests on: the disagreements were read as a streak rather than as today's number, and worked down until the ones that remained were ones somebody could explain. If you are reading this before cutover, that work is already behind you — go to Step 2.

The one thing worth carrying out of that guide and into this decision: if Arcvue would do something natively after cutover, it has to work NOW. A disagreement you resolve with "the legacy system is authoritative for this today" is a rail you have not built, and cutover day is the worst possible moment to discover it.

Step 2 — Watch the pipeline, not just the ledger​

Where the detail lives: Flightdeck

Flightdeck shows whether every feed is arriving, being coded and reaching a ledger that balances. It shows the same boxes before and after cutover — there is no box comparing Arcvue against the system you are leaving, so the board will not mark the moment cutover happens. Read it the way you will read it every day afterward: a red there is a feed or a step to fix before you rely on the books, cutover or not.

Step 3 — Set up the subledger ties BEFORE you cut over​

Where the detail lives: Subledger Ties

Do this before cutover, not after, and the reason is the point: the parallel run stops answering the day the legacy system is switched off. There is no comparison left to run. A subledger tie compares Arcvue's own detail against Arcvue's own control account, so it keeps asking the same question forever — it is the control that replaces the parallel run, and you want it already configured and already signed off once before you need it.

Step 4 — Find out which period your opening balances were booked into​

Where the detail lives: Subledger Ties, Record the opening balance

You are about to be asked for a boundary period, and the opening-balance period is the input that decides which answer is correct. Most people do not have it to hand at the moment they are asked. Look it up now.

Step 5 — Decide the boundary, and have it recorded​

Who records it: your Arcvue implementation contact. There is no cutover screen — it happens once per segment, so it is recorded on your instruction rather than offered as a control anyone could press by accident.

Two inputs, both yours: the segment (legal entity) and the boundary period — the first month Arcvue is authoritative for that segment.

It must be the month after your opening batch (Step 4) — not merely a month that is still open, which is the trap, because the opening-balance month is open on the day you name it and the failure it causes does not appear for weeks. Arcvue refuses a boundary that is malformed, already closed or locked, or at or below the opening batch.

The record keeps who decided, when, the period, and what the readiness checks said at that moment. That record is the point; the exact confirmation phrase it requires is only there to stop a misplaced action.

Recording the boundary does not switch anything on that day. Arcvue reads the boundary as a date, so the segment changes over when the boundary month begins; a boundary recorded early simply waits for its month.

Step 6 — Expect the queue to fill​

Where the detail lives: Bookkeeper

During the parallel run, Arcvue deliberately withholds transaction-coding work from the bookkeeper queue — coding transactions in Arcvue while another system is authoritative is exactly the wrong direction, so those items are suppressed rather than shown and ignored.

They are not suppressed once the boundary month begins. So the first thing many controllers notice is a queue that was quiet for months and now has work in it. That is the system starting to ask you the questions it was holding back, not a backlog that accumulated unseen.

Step 7 — Close the first month​

Where the detail lives: Close a Month · Year-End Close

The first close after cutover is the first one that is entirely yours. Two things change:

  • The subledger ties from Step 3 now carry the weight the parallel run used to carry. They appear on the close checklist as a flag.
  • Year-end behaves differently. Read the year-end guide for what Arcvue performs itself versus what it mirrors — the answer changes at cutover and it is not the kind of thing to discover in December.

Part 3 — When something looks wrong​

I cannot find a cutover screen. Expected — there is none. Cutover happens once per segment and is recorded by your implementation contact on your instruction (Step 5). It is not evidence that the feature is missing or unfinished.

My boundary period was refused. The three refusals about the period are a malformed period, a month that is already closed or locked, and a month at or below your opening batch — and the last one is the one that catches people, because such a month is usually still open. Name the month after the opening batch (Step 4).

Cutover was refused over unresolved consumers. Something still reads the ledger you are retiring and no decision has been recorded about what happens to it. This is a real refusal and it is protecting you — the thing still reading that ledger would simply stop returning data. Raise it with whoever maintains your integrations rather than trying to force the change.

One-line summary​

Cutover is a decision, not a gate: set up your subledger ties first because they are what replaces the parallel run, look up the period your opening balances landed in, then have your implementation contact record each segment's boundary — the month after that period — and expect the bookkeeper queue to start asking you the questions it was holding back once that month begins.