Can I Move a Print Queue to Another Printer? (w/Examples) + FAQs

Yes, you can move a print queue to another printer, and in most cases the process is straightforward if you plan for driver compatibility, port changes, and client redirection. A print queue is not glued to one physical device. It is a logical object that lives on a print server (or a local computer) and points to a port, a driver, and a set of permissions. You can redirect that object to a different printer, copy it to a new server, or rebuild it on a replacement device.

The rules that govern print queue migration come from a mix of places. On Windows, the Print Management console and the built-in Printbrm.exe tool give you supported migration paths. On macOS and Linux, the CUPS lpadmin command edits queues directly. Cloud workloads lean on Microsoft Universal Print for a serverless model. If you skip driver checks, mishandle ports, or forget Group Policy, jobs will stall, users will print blank pages, or the spooler will crash.

According to a 2025 Quocirca Global Print Security Landscape report, 67% of organizations experienced a print-related data loss in the past 12 months, and botched migrations are a leading trigger. That makes a careful move more than a convenience; it is a security control.

• 🖨️ How to move a print queue on Windows, macOS, and Linux step by step
• ⚙️ The difference between redirecting a queue and recreating it on new hardware
• 📜 Which Microsoft tools, CUPS commands, and PowerShell cmdlets work best
• 🧩 Real named examples covering printer replacement, server consolidation, and cloud migration
• 🚫 The most common mistakes that break print jobs and how to avoid them

What a Print Queue Actually Is

A print queue is a software object, not a piece of hardware. It holds pending print jobs, enforces permissions, and hands work off to a driver that talks to a port, which in turn talks to the physical printer. When you “move” a queue, you usually change one of those pointers: the port, the driver, or the host server.

Microsoft defines a print queue inside the Windows print subsystem as a named logical printer bound to a driver and a port. The Open Printing CUPS project uses a similar model, where each queue has a device URI and a PPD or driverless IPP profile. Both systems let you rebind the queue to a different device without destroying user mappings, which is why moving is possible in the first place.

Why You Would Move a Queue

The most common reason is a hardware swap. A printer dies, and the replacement is a different model but needs to keep the same queue name so that hundreds of users do not have to remap printers. Another reason is server consolidation, where several old print servers collapse into one. A third reason is migrating to a cloud service like Universal Print that removes the on-premises server entirely.

Each reason carries a different risk profile. A hardware swap risks driver mismatch. A server move risks broken Group Policy. A cloud migration risks losing features like pull printing. You must match the method to the risk.

The Governing Rules

On Windows, the supported migration tools are documented in Microsoft Learn’s print server migration guide. On macOS and Linux, the CUPS Administration Guide governs queue edits. Enterprise print policies may also fall under HIPAA Security Rule 45 CFR 164.312 if protected health information passes through the queue. Ignoring that rule can trigger civil penalties up to 1.5 million dollars per violation category per year.

A plain-English version is simple. Keep an audit trail. Encrypt jobs in transit. Do not leave old queues spooling PHI after a migration.

Moving a Print Queue on Windows

Windows gives you four supported paths. You can use the Print Management snap-in GUI, the command-line Printbrm.exe tool, the PrintManagement PowerShell module, or a registry-based clone. Each one has trade-offs in speed, fidelity, and risk.

The GUI is best for small batches. Printbrm.exe is best when you need to script an export. PowerShell is best when you need granular control over individual queues. The registry clone is a last resort for legacy Windows Server 2008 R2 boxes where other tools fail, as discussed in this Microsoft Tech Community post.

Using the Print Management Console

Open the console by pressing Windows key + R, typing printmanagement.msc, and pressing Enter, as described in the PaperCut migration guide. Select the source server, click Action, then Migrate Printers. Choose Export printer queues and printer drivers to a file. Save the resulting .printerExport file to a network share.

Move to the target server, open Print Management again, and choose Import printer queues and printer drivers from a file. Pick the file. The wizard restores queues, drivers, ports, and permissions. It does not move pending jobs, so drain the spooler first.

The consequence of skipping the pre-drain step is simple. Users lose whatever jobs were in flight. A common misconception is that the wizard carries active jobs; it does not.

Using Printbrm.exe

Printbrm.exe is the command-line engine behind the GUI. The basic export is printbrm -b -s \\SourceServer -f C:\backup\printbackup.printerExport, and the import is printbrm -r -s \\DestinationServer -f C:\backup\printbackup.printerExport, as shown in the PaperCut Print Migrator walkthrough.

The tool ships with every supported Windows Server edition. It handles 32-bit and 64-bit driver packages, but only if both driver sets exist on the destination. If you try to import an x86 driver onto an x64 server without the matching package, the queue restores but jobs fail with a driver unknown error. A common misconception is that Printbrm rewrites drivers; it does not.

Using PowerShell

PowerShell gives per-queue control. Use Get-Printer to list queues, Add-Printer to recreate them, and Add-PrinterPort to rebuild ports. A simple redirect looks like Set-Printer -Name "AcctgHP" -PortName "IP_10.0.0.55", which points the existing queue at a new printer IP.

The consequence of changing only the port without updating the driver is misaligned PCL or PostScript output. A real example comes from a Spiceworks community thread where an admin remapped 500 users with a short script that replaced the old server name in the user’s printer connection string.

Registry Clone Method

For legacy edge cases, you stop the spooler service, export HKLM\SYSTEM\CurrentControlSet\Control\Print\Printers and the Monitors key, copy the spool files, import on the target, and restart the spooler. This method is documented in a Reddit sysadmin thread.

The consequence of a bad registry merge is a spooler that will not start. A common misconception is that this method preserves driver files; it does not. You must copy the driver files from C:\Windows\System32\spool\drivers by hand.

Moving a Print Queue on macOS

macOS uses CUPS under the hood. You can move a queue by editing it with the lpadmin command or by exporting the printer list from System Settings and rebuilding it on the new Mac.

The lpadmin approach is fast. The command sudo lpadmin -p AcctgHP -E -v ipp://10.0.0.55/ipp/print -m everywhere reassigns the queue named AcctgHP to a new device using the driverless IPP Everywhere profile. This pattern is confirmed in an Apple Support discussion on redirecting CUPS queues.

Backing Up CUPS Queues

Copy /etc/cups/printers.conf and the /etc/cups/ppd/ directory from the old Mac to the new one. Restart CUPS with sudo launchctl stop org.cups.cupsd and then start it again. The CUPS documentation warns that printers.conf should never be edited by hand while the daemon runs. The consequence of live editing is file corruption and lost queues.

A real-world example: a design studio upgrades every Mac to Apple silicon. They copy printers.conf to the new iMacs and every queue appears with the correct name and share. A common misconception is that AirPrint queues migrate the same way; they rebuild automatically on first use.

Reassigning a Queue to New Hardware

If the old printer dies and a new model takes its place, you do not need to delete the queue. Run sudo lpadmin -p QueueName -v ipp://newprinter.local/ipp/print -m everywhere. The queue keeps its name, its jobs, and its permissions, but now it talks to the new device.

The consequence of picking the wrong PPD file is garbled output or missing tray options. A common misconception is that everywhere mode supports every feature; it covers basics like duplex and color, but vendor-specific finishers may need the vendor PPD.

Moving a Print Queue on Linux

Linux uses the same CUPS stack as macOS. Tools like GNOME system-config-printer or the CUPS web interface at http://localhost:631 give you a GUI. Command-line users rely on lpadmin.

Exporting and Importing

Copy /etc/cups/printers.conf, /etc/cups/classes.conf, and the /etc/cups/ppd/ folder to the target machine. Stop cups with sudo systemctl stop cups, place the files, and start cups again. The Debian CUPS wiki confirms this is the supported approach.

The consequence of mixing CUPS versions is parser errors that hide specific queues. A common misconception is that cupsd will auto-heal; it will not, and it logs the failure in /var/log/cups/error_log.

Redirecting With lpadmin

Run sudo lpadmin -p QueueName -E -v socket://10.0.0.56:9100 -P /etc/cups/ppd/vendor.ppd to redirect a queue to a new printer using raw socket printing on port 9100. This is handy when a replacement printer arrives with a different IP.

The consequence of leaving the old device URI in place is that jobs vanish into a dead IP. A common misconception is that CUPS reports the failure to the user; by default, it retries silently.

Moving to Microsoft Universal Print

Universal Print is a cloud-based print service that removes the need for an on-premises print server. You register printers directly with Microsoft Entra ID and assign them to users through the Azure portal.

The Connector and Queue Migration

If your printer is not Universal Print ready, install the Universal Print connector on a Windows 10 or later machine. The connector publishes existing Windows queues to the cloud. You then share them with users through Entra groups.

The consequence of skipping the Entra license check is that users cannot see the printer. Every user needs a Universal Print license, which is bundled with Microsoft 365 E3 and above. A common misconception is that the connector preserves all GPO settings; deployment must be redone through the Universal Print portal.

Three Real-World Scenarios

Each scenario below walks through a common migration path and the outcome you should expect. All three map to the official Microsoft, Apple, and CUPS guidance cited above.

Scenario 1: Dead Printer, Identical Replacement

Scenario 2: Different Model Replacement

Scenario 3: Full Server Consolidation

Named Examples You Can Follow

Every migration is easier when you model it on a story. The three examples below are composites based on common help-desk tickets and public case studies.

Example 1: Maria at a Hospital

Maria runs IT for a 200-bed hospital. The radiology department’s printer fails, and she installs a different vendor’s model at the same IP. She opens Print Management, right-clicks the existing queue, and changes the driver to the new vendor’s PCL 6 driver. She keeps the queue name RadPrint01. Because the queue name never changed, the 40 workstations in radiology print to it the next morning with no reconfiguration. Maria also documents the change to satisfy the hospital’s HIPAA Security Rule audit controls.

Example 2: Darnell at a Law Firm

Darnell is the sole sysadmin at a 60-lawyer firm. The firm’s Windows Server 2016 print server is at end of life. He installs Windows Server 2025, runs Printbrm.exe on the old server to create a .printerExport file, copies it to the new server, and imports it. He then creates a CNAME record pointing the old server name to the new one so no GPO edits are needed. Every queue works on Monday morning without a single help-desk ticket.

Example 3: Priya at a Design Studio

Priya manages 30 Macs at a branding studio. She retires a color plotter and brings in a new Epson SureColor. She runs sudo lpadmin -p ColorPlotter -v ipp://10.0.1.44/ipp/print -m everywhere on a single admin Mac, then pushes the updated printers.conf via Jamf to the rest of the fleet. The queue name stays the same, and the designers submit jobs without noticing the hardware swap.

Mistakes to Avoid

Small errors in a print queue move create huge downstream pain. The list below covers the most common ones and the real-world outcome of each.

• Skipping the driver pre-install on the destination server causes every job to fail with an Unknown Driver event in the System log.
• Forgetting to stop the spooler service before a registry clone leads to a half-written printers key and a spooler that will not start.
• Ignoring 32-bit and 64-bit driver parity means legacy clients print blank pages while modern clients work fine.
• Leaving stale queues on the old server causes users to send jobs to a dead server and lose confidentiality of documents, which can violate HIPAA Security Rule 45 CFR 164.312.
• Missing the PrintNightmare CVE-2021-34527 patch on either server exposes both endpoints to remote code execution during the migration window.
• Not updating the GPO printer deployment points thousands of users at the retired server name, leading to failed logons and slow policy refresh.
• Forgetting to back up the printers.conf file on Linux or macOS makes a rollback impossible if the new queue misbehaves.
• Relying on IP addresses instead of DNS names locks you to a specific subnet and breaks the queue when the printer moves to another VLAN.
• Assuming Universal Print inherits GPO settings removes pull-print features, color restrictions, and departmental quotas overnight.
• Using the wrong print processor, such as sticking with a vendor processor instead of WinPrint, triggers the driver restore issue flagged by the Microsoft AskPerf blog.

Do’s and Don’ts for Print Queue Migration

The list below summarizes the behaviors that separate clean migrations from painful ones. Each item includes the reasoning behind it.

• Do drain the spooler before export, because pending jobs do not travel with Printbrm or the Print Management wizard.
• Do install 64-bit and 32-bit drivers on the destination before import, because driver mismatch is the single largest cause of post-migration failures.
• Do document every queue name, port, and driver, because rollback depends on knowing the original state.
• Do test with a pilot group of 10 users, because a small canary uncovers driver quirks before the rest of the company is affected.
• Do use DNS CNAME records to alias the old server name, because a CNAME removes the need to edit Group Policy, logon scripts, or user-mapped printers.
• Don’t edit printers.conf while CUPS is running, because a live edit corrupts the file.
• Don’t delete the old queues on day one, because users sometimes hold printer mappings in local profiles and you need a fallback.
• Don’t migrate without patching both servers for PrintNightmare, because an unpatched spooler is a remote code execution target.
• Don’t assume vendor-specific finishers survive a driverless IPP move, because features like stapling need vendor PPDs.
• Don’t mix print server roles with domain controller roles, because the combined attack surface violates Microsoft’s security baselines.

Pros and Cons of Moving a Queue Versus Rebuilding

Every admin faces the same fork in the road: move the queue or rebuild from scratch. The list below captures the trade-offs.

• Pro: Moving preserves user mappings, permissions, and share names, which cuts help-desk tickets to near zero.
• Pro: Printbrm.exe and Print Management are free and supported, so there is no license or tooling cost.
• Pro: PowerShell gives granular control, which helps when only a handful of queues need to move.
• Pro: CUPS queues move with a simple file copy, which is faster than any GUI on small fleets.
• Pro: A preserved queue name means no changes to embedded scanners, label printers, or legacy line-of-business apps.
• Con: Moving can carry forward old drivers, which may include unpatched vulnerabilities.
• Con: Moving locks you into the old naming scheme, which may be inconsistent or confusing.
• Con: Some features, like custom print processors, do not always migrate cleanly.
• Con: Rebuilding forces every user to re-map printers, which spikes help-desk volume for a week.
• Con: Rebuilding risks losing custom permissions that were set ad hoc over years and never documented.

Step-by-Step Windows Process With Every Choice Explained

The Print Management migration wizard presents a series of screens, and each screen contains a decision with consequences. The detail below walks you through every one.

Step 1: Choose Export or Import

The first screen asks whether you are exporting or importing. Pick Export on the source. The consequence of picking Import here is that the wizard will ask for a file that does not yet exist and the operation will fail.

Step 2: Select the Source Server

Type the UNC path of the source server, such as \\OldPrintSrv. The wizard enumerates every queue. The consequence of a typo is a timeout that can last five minutes before it reports the server as unreachable.

Step 3: Pick Objects to Export

By default, Print Management exports queues, drivers, ports, and processors. You can uncheck items. The consequence of unchecking drivers is a faster export but a broken import on a server that does not already have the drivers installed.

Step 4: Save the File

Save to a local path, not a network share, because network interruptions can corrupt the file. The resulting .printerExport is a cabinet file that you can inspect with any CAB-aware tool.

Step 5: Run the Import

On the destination, run the wizard in Import mode. You can choose to overwrite existing queues or skip them. The consequence of choosing Overwrite is that any locally created queue with the same name is replaced, including its permissions.

Step 6: Post-Import Validation

Open the Event Viewer and filter for PrintService operational logs. Verify that each queue reports ready. Print a test page from a client. The consequence of skipping this step is that users become your QA team.

Court Rulings and Precedents That Shape Print Migration

US case law on print queue management is thin, but several rulings touch the data that flows through them. In United States v. Anthem (2018), the HHS Office for Civil Rights fined Anthem 16 million dollars over a data breach that highlighted weak access controls, a category that includes print queue permissions.

The Federal Trade Commission v. Wyndham Worldwide ruling confirmed that the FTC can punish companies for weak IT hygiene, including poorly managed endpoints. A print server full of stale queues pointing at decommissioned printers is exactly the kind of hygiene failure the court was concerned about.

State privacy laws, like the California Consumer Privacy Act, give residents a right to know what personal data an organization holds. Print spool files can contain that data, so a migration plan should document what gets deleted and when.

Key Entities You Need to Know

A print queue migration involves more players than most admins realize. The list below names the key actors and their roles.

Microsoft publishes the Windows print stack and the Printbrm.exe documentation. Apple ships CUPS inside macOS and coordinates with the OpenPrinting project that maintains the open-source CUPS codebase. The Mopria Alliance defines the driverless print standards that IPP Everywhere relies on.

On the regulatory side, the HHS Office for Civil Rights enforces HIPAA, the Federal Trade Commission polices unfair data practices, and the National Institute of Standards and Technology publishes the SP 800-53 controls that federal systems follow. Enterprise print tools like PaperCut and PrinterLogic add pull-printing, audit trails, and migration helpers on top of the native stack.

FAQs

Can I move a print queue without reinstalling drivers on clients?

Yes. The driver lives on the server in a server-side deployment, so clients download the updated driver automatically the next time they print, as described in the point and print documentation.

Can I keep the same queue name when moving to new hardware?

Yes. Both Windows Print Management and CUPS lpadmin let you rebind a queue to a new device without renaming it, which preserves every user mapping.

Can I use Printbrm.exe to move queues between different Windows versions?

Yes. Printbrm.exe supports cross-version migration from Windows Server 2008 R2 forward, provided the destination has the matching drivers installed.

Can I move a local printer queue to a network printer?

Yes. Install the new network driver, create a TCP/IP port, and use Set-Printer to rebind the existing queue to the new port with one PowerShell command.

Can I migrate print queues to Universal Print without a server?

Yes. The Universal Print connector publishes existing queues, and printers that ship with native Universal Print support skip the connector entirely.

Can I lose print jobs during a queue migration?

Yes. Jobs in the spooler at the moment of export are not carried to the new server, so drain the spooler before you start or users will lose in-flight work.

Can I run two print servers in parallel during a cutover?

Yes. Many admins leave the old server online for a week as a fallback, then decommission it after confirming the new server handles every department without errors.

Can I migrate printer permissions along with the queue?

Yes. Printbrm.exe and the Print Management wizard copy the ACLs set on each queue, preserving the exact access list from the source server.

Can I move a CUPS queue by copying printers.conf?

Yes. Stop the cups service, copy printers.conf and the matching PPD files, and start cups again, as covered in the CUPS admin guide.

Can I use Group Policy to repoint clients after a queue move?

Yes. The Deploy Printer Connections GPO feature pushes the new UNC path at user or computer logon with no user action.

Can I automate a large migration with PowerShell?

Yes. The PrintManagement module exposes every queue property as a cmdlet, so you can script exports, imports, and port changes across hundreds of servers.

Can I move a print queue that uses a custom print processor?

Yes. Copy the processor DLL to C:\Windows\System32\spool\prtprocs\x64 on the destination before import, or the queue will fall back to WinPrint and some features will break.