Most office cutovers look finished on paper long before they are finished in practice. Files are in the cloud. Mail is hosted. The domain controller role has a replacement. The license renewal has been deferred. Then someone tries to print a settlement letter, scan a signed engagement letter into a matter folder, or open the one desktop app that still talks to a database on the closet server, and the migration freezes.
Printers, scanners, and a short list of holdout applications are the workloads that block cutover most often. They are not glamorous. They do not show up in architecture diagrams. They are also the parts of the day that staff notice within minutes when they break. A migration that treats them as cleanup after the big move will spend weeks in a half-retired state, with the old server still powered on because three people cannot do their jobs without it.
Why print and scan stall the plan
Print is a social system as much as a technical one. The office has a shared queue, a few personal printers, and a mental model of which machine is closest to which desk. On the closet server, that model is usually implemented as a print server role plus a handful of shared printers with drivers that were installed years ago and never revisited. When the server goes away, every workstation that was pointed at \\SERVER\HP-3rd-Floor loses its path. Cloud print services and direct IP printing both work, but neither is a free swap. Direct IP printing means each machine needs the right driver and the right address. Cloud print means authentication, a supported device list, and a week of people asking why the duplex setting disappeared.
The failure mode is not subtle. Someone prints a document for a client meeting, nothing comes out, and the meeting still happens. That person will escalate. If the only fix is "turn the old server back on," the cutover date was fiction.
Scanners create a quieter problem with a sharper edge. Many offices still scan to a network folder. The multifunction device has an address book entry that drops PDFs into \\SERVER\Scans\Intake or a matter-specific path. That path is often the only automation in the building. Reception scans. Accounting scans. Paralegals scan signed pages that never touch email. When the file share moves to a cloud drive, the scanner does not automatically learn the new destination. Some devices can scan to email or to a vendor cloud inbox. Some cannot without a firmware update, a paid connector, or a replacement unit. Until that path works again, people invent workarounds: email to themselves, USB sticks, desktop folders that never get filed. The old server stays up because the scan destination still resolves there.
USB scanners attached to individual PCs are easier to keep, but they often depend on local software that expects a drive letter or a TWAIN path that was configured against the old share. The scanner still powers on. The software still opens. The save dialog still points at a dead location. That counts as broken.
The last three apps
After print and scan, the remaining blockers are usually three applications or fewer. The number is not magic. It is a pattern. The migration team has already moved the obvious tools: email, calendar, file storage, the main line-of-business suite if there is a cloud edition. What remains are the apps that were installed once, used by a minority, and never budgeted for replacement because they "just work."
The first common holdout is a desktop client that talks to a database or license service on the office server. Time and billing packages, older document management front ends, and specialty practice tools still ship this way. The client installs fine on a new laptop. The login fails because the server name in the config is still the closet machine, or because the app expects a LAN address and the user is now on VPN with a different topology. Moving the database to a hosted SQL instance or a vendor cloud edition is real work. Leaving it on the server means the server cannot be powered off.
The second holdout is an app that only one or two people use, loudly. A conflict checker. A forms filler. A scanning utility that does OCR better than the MFP. Because the user base is small, it never made the migration spreadsheet as a first-class line item. Because those users are essential on filing deadlines, the app becomes a veto. The honest move is to put it on the list early with an owner, a replacement candidate, and a date. The dishonest move is to hope the people who rely on it will tolerate a broken week.
The third holdout is anything that depends on a local path, a mapped drive, or a scheduled import that still reads from the old share. Macros, mail merges, and "integrations" that are really a CSV dropped in a folder overnight all belong here. They look like features of the new cloud apps until someone notices the overnight file never arrived. These are the same class of workload that scheduled-task migrations catch, and they often share infrastructure with print and scan because they all grew up around the same file share.
If you only have bandwidth for one meeting before cutover week, make it a working session on these three apps plus print and scan. Ask who opens them, what happens if they are offline for a day, and what the vendor's current supported path is. Write the answers down. A verbal plan evaporates the first time a partner asks when the old server can be unplugged.
What a clean unblock looks like
Treat printers as a cutover workstream with a named owner, not as a footnote under "network." Inventory every shared queue and every personal printer that staff still use. Decide, per device, whether the path is direct IP, a cloud print service, or replacement. Install and test from a sample of workstations before the file share cutover, not after. Include a reprint test of something that matters: letterhead, envelopes, a multipage PDF with duplex. Cosmetic success on a test page is not enough.
For scanners, map every destination the devices write to today. If the destination is a folder on the retiring server, pick the replacement before the share moves: cloud folder with a connector, email-to-matter workflow, or a small always-on appliance that is not the domain controller. Test a real scan into a real matter folder with the people who scan every morning. If the device cannot reach the new destination, that is a procurement problem, not a training problem.
For the holdout apps, force a decision into one of three buckets. Replace with a cloud edition on a fixed date. Rehost the backend so the client no longer needs the closet server. Or formally keep a minimal host for that app alone, with a written end date and no other workloads on it. The third option is sometimes correct for a quarter. It is wrong as a permanent posture, because the "temporary" box accumulates DNS, backups, and the next license renewal by inertia.
Cutover is blocked when any daily path still requires the retiring server. Print, scan, and the last three apps are daily paths. Move them from the cleanup list to the critical path, give them owners and dates, and the rest of the migration can finish without leaving a humming machine in the closet that nobody is willing to shut down.