Retiring an on-premise fax server is a different exercise from retiring fax machines, and the difference is not size. A machine has a number and a location. A server has an account list, routing rules that accumulated over years, an archive somebody may be obliged to keep, and integrations that were configured by people who have moved on.
If you are retiring desk machines rather than a server, migrating from fax machines to cloud fax is the sequence you want. This is the harder case.
What you are actually migrating
- Numbers. Usually more than anyone expects, because a server made it cheap to allocate them.
- Users and groups, with entitlements that may not match anybody's current role.
- Inbound routing rules, which are the institutional knowledge in this system.
- Integrations. Anything that submits to the server programmatically, or that watches a folder.
- The archive, and the retention obligation attached to it.
- Cover pages and templates, which are trivial until somebody's audit requires one.
Start with an inventory, and expect it to be wrong
The routing table is the document that matters, and it is almost never current. Rules exist for departments that reorganized, for people who left, and for workflows that ended. Some route to mailboxes nobody monitors.
The efficient way to establish what is live is to measure rather than to ask. Take a period long enough to include a monthly cycle, and look at which numbers actually received traffic and where it went. Numbers with no inbound traffic for a full cycle are candidates for retirement rather than migration, and retiring a number is far cheaper than porting one.
Ask the same of outbound. Server logs will show which systems submit, and it is common to find one nobody could name.
Number porting sets the timetable
This is the critical path, and it is largely outside your control once submitted. Numbers are printed on forms in circulation and held in the address books of organizations you cannot survey.
Two rules save projects here. Start porting early, before the rest of the work looks ready, because the elapsed time is not compressible at the end. And do not port everything at once: a first group of low-traffic numbers proves the process and surfaces the paperwork problems while the stakes are low.
Integrations are where the schedule slips
A fax server usually has at least one system submitting to it, and the interface is frequently a watched folder or a command-line utility rather than anything documented. Those integrations do not fail loudly when the server goes away; they fail silently, and are discovered when somebody notices a process stopped producing output.
Find them by watching the server rather than by asking. Then decide, per integration, whether it moves to the service API, moves to email submission, or is retired because the workflow behind it ended years ago. Our page on API-to-fax integration covers what the first option involves.
The archive is a records decision, not a technical one
The stored fax history is the part most likely to be handled badly, because it is the part with an obligation attached and no obvious owner.
Three questions settle it. What is in there, and how long must it be kept. Who is obliged to keep it, which is a records question rather than an IT one. And where will it live once the server is gone, because "on the old server" stops being an answer the moment the hardware is decommissioned.
Export it before you need it, and verify the export is readable independently of the system that produced it. An archive in a proprietary format on a machine nobody can boot is not a retained record. Electronic fax audit trails and records management covers what a record should contain.
A sequence that works
- Measure traffic for a full cycle. Establish which numbers and integrations are live.
- Decide what is retired rather than migrated. This is the largest saving available.
- Export and verify the archive, with the retention obligation established in writing.
- Begin porting the first group of numbers.
- Move users, starting with the highest-volume group, so problems appear where somebody will report them.
- Move integrations one at a time, each with a rollback.
- Run both in parallel until a full cycle has passed with no traffic on the server.
- Decommission, and cancel the lines. This step is skipped remarkably often.
What goes wrong
The recurring three: porting started too late; an integration nobody knew about; and an archive whose retention obligation was discovered after the server was gone. All three are found by the inventory, which is why it is worth more than it feels like at the time.
Running both at once
Parallel running is the part people try to shorten and should not. The server keeps answering its remaining numbers while the service takes the ported ones, and for a period both are live.
That period should cover at least one full business cycle, because the traffic you are trying not to break is precisely the traffic that does not happen weekly. An annual reporting deadline, a term start, a quarterly submission: each brings a partner organization that faxes once and expects it to work. A migration validated over three quiet weeks in the summer will be tested in earnest months later, by which time the server has gone.
Where to go next
For the underlying comparison, see cloud fax versus on-premise fax. To plan a specific migration, tell us what you are working with, or see pricing.
Sources
- NIST SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations. Contingency planning and the Audit and Accountability family, for the archive and parallel-running questions.
- ITU-T Recommendation T.38. Procedures for real-time Group 3 facsimile communication over IP networks, in force at edition 11/15.