The process for moving your PaperCut MF Application Server between two on-premises servers is the same whether you’re moving it to a cloud platform hosted by Google, Microsoft, or Amazon. The distinction is in the extra work you’ll put in up front to make sure cloud hosting is appropriate for your business and in the back end to confirm that your solution still works as planned after moving to remote infrastructure.
Consider the following issues before you start planning such a migration:
Q Is my internet connection reliable and fast enough for my company to rely on it for printing?
Moving to a cloud-hosted solution may bring issues if your location is cause for your internet connection to be prone to outages or not especially fast. Users may experience delays with print job submission and release if MFDs periodically behave strangely if their connection to the remote Application Server is unreliable.
Q In the event of an internet outage, how forgiving would my organization be of a printing delay?
If there is an internet outage when the PaperCut MF Application Server is hosted in the cloud, your users might not be able to print until the problem is fixed. Deploying a Site Server locally is one approach to offset this, but if the objective is to significantly reduce or completely eliminate the requirement for on-site infrastructure, you might want to avoid doing so.
MFDs integrated with PaperCut MF may not be able to facilitate copying and scanning during any such outages, but secondary servers or Direct Print Monitors hosted locally can be configured using failure modes to enable printing to continue in the event that the Application Server is down, with print jobs being logged once connectivity is restored.
Q Do I want to host my print server in the cloud or maintain print tasks on-site at my business?
It is frequently possible to host your print server(s) in the cloud with your PaperCut MF Application Server if you have a sufficiently fast and reliable internet connection. Print jobs will be sent from your users’ workstations to the remote print server through a WAN link before being released and sent back to the on-site printer.
However, due to the size of print job spool files, using bandwidth for this reason could be expensive depending on your plan and Internet Service Provider’s rules. If your connection is not particularly fast, your users might also discover that printing is less responsive than it was with a local print server. Their jobs might take longer to become available for release, and they might also discover a delay between releasing a job and the printer actually printing it.
You can continue to host your print server(s) locally with a Secondary Server deployed to communicate print job details to the remotely hosted Application Server and enforce any print policies as necessary if you want to reduce the load on your WAN connection or for any other reason do not want your users’ print jobs to travel over the internet.
If you’d prefer to get rid of any locally hosted infrastructure, including print servers, another choice is to switch to our Direct Print Monitor, which works best when combined with Print Deploy. The print and release workflow can be completed while keeping print jobs local to a user’s workstation thanks to these features. If you have previously relied on a typical print server and client approach for printing, this will represent a substantial change in architecture. Please carefully review the available documentation to make sure it meets your needs.
Q Am I equipped to use a VPN to encrypt the link between my local network and the distant cloud servers?
A VPN or VLAN must be set up to secure communications between your cloud-hosted server(s) and the nearby MFDs and workstations. If not, some portion of the network traffic involved in your solution may pass through the open internet in an unencrypted format, exposing sensitive information to snoopers.
Extremely sensitive data is almost always transmitted in an encrypted format thanks to PaperCut MF’s satellite solution components, which protect it from such unauthorized observation even within your local network. For instance, passwords used for authentication will never be made publicly available in cleartext. Nonetheless, certain data might be able to be extracted from packets passed back and forth between the local and distant solution components without the usage of a VPN or separated network connection.
This information could include details like usernames, document names, and internal network IP addresses if print jobs are stored locally. The contents of printed papers themselves could be made public if print jobs are sent over a public network and the print protocol being used is not secured. Therefore, it is strongly advised that you only move forward with a Private Cloud solution if you can use a VPN or other comparable technique to protect all user data as it travels between endpoints.
Fortunately, most cloud hosting services are designed specifically for this kind of usage, with the goal of making any remote servers only appear as though they were connected to your local network. Your private cloud deployment can be just as secure in practice as one that is locally hosted—even it’s expected!
Interested in learning more? Email us email@example.com to get more about hosting scenarios and how we can help you make your business more efficient. Fill out the form below to learn more!