Migrating Your Servers to the Cloud

Introduction

Not unlike other industries, the Information Technology world has a way of hyping anything new as always better. The implication is sticking with what works means you'll be left behind. It's more pronounced in IT, because information technology equipment and software continue to grow in capabilities by leaps and bounds. One way some businesses might feel left behind is by having servers in a back room or closet in their office, running custom applications for the employees, storing files and folders, and managing printing. As virtualization technology matured about 15 years ago, the push to move this to the cloud really took off. If you still have on-premises servers, here are some ideas on your options.

Basic Server Functions

If your server only does the basics, such as storing shared files, then moving to the cloud requires only setting up the new file sharing service, configuring security and policies, copying your files during the designated cutover time, and redirecting your users to the new service. Then you can shut off your server forever. You won't pay for maintaining the server or replacing failed parts, but you will likely need to pay monthly to the cloud file storage provider for its services. There may also be a little bit of retraining for the new way to access files, but pretty much all users these days have no problem figuring out how to access and use files stored in the cloud by using a web browser or sync apps.

The "cloud" refers to applications and data on remote servers managed by third party providers, and accessed by users over the Internet. Years ago, when your remote applications and data were on a specific server in one known location, it was called "remote hosting" or just "hosted". Today's service providers run software and store data in any of the millions of servers that have been built out to work together to service billions of users quickly. Its nebulous nature is one reason the "cloud" moniker has stuck.

If that same server handled printing, you would need to reconfigure workstations to print directly to each printer, which is a little less manageable than using a central print server. Or, after the files are migrated, you might wish to leave the server in place just for the print function.

You may still be running an in-house e-mail server. If this is the case, your users are likely missing out on the standard functionality everyone expects from widely used modern e-mail systems such as Microsoft 365, Gmail, Apple iCloud, or Outlook.com. In addition, any power outage in your office or server failure means your e-mail goes offline, which is intolerable for almost any business in today's world where old-fashioned e-mail is still the standard for written communications, and the ubiquity of e-mail on mobile phones means prompt replies are expected.

Migrating your e-mail system to the cloud doesn't really have any cloud-specific considerations, though. It goes just like any migration from one e-mail hosting provider to another, the same as in the pre-cloud era. That's because e-mail is mostly about the communications and security, which use well-established protocols that don't rely on cloud computing, and the migration part involves copying user accounts and the contents of the user mailboxes. It is an involved process, which will require users to update their e-mail apps on their computers or phones to connect after the migration, but an experienced IT provider can certainly get this whole project done without interrupting mail flow. Once an e-mail system is moved to the cloud, the most valuable benefit will be the expected uptime, as cloud-hosted e-mail systems hosted by major providers almost never go down.

Custom Applications

Apart from the above, in-house servers provide their best value by running custom applications to support your business, or even to service your customers if they can log in directly to the server. Once the server itself starts getting old and your IT service provider suggests buying a new one, you might consider moving the application and data to the cloud so long as you're being forced to invest anyway.

You'll have to consider that there will now be a monthly cost for hosting your application and data, which may be more or less than what you spend in the aggregate maintaining your in-house server (including buying a new one every so many years).

Also, security will have to be re-engineered from scratch, as having your data and services running on third-party servers in the cloud presents a completely different attack target for criminals than a server in your office behind a firewall, especially if your current setup doesn't allow direct access to the server from the Internet. How the server can be discovered, how your application software is protected from malicious connection attempts on the new platform, how infiltration is detected, and whether encryption is required for data at rest or in transit are just some factors that will change.

That said, here are several options for moving your local, custom applications running on an in-house server (called "legacy applications") to the cloud.

  • Rebuilding the application
  • P2V migration
  • Not migrating

Let's discuss.

Rebuilding

This involves your system manager and/or a software developer subscribing to a cloud hosting provider, allocating resources, picking an operating system and/or software platform, and transferring your custom application while modifying it to run on the selected platform.

Depending on what language or platform your old in-house application ran on, it may require a complete rewrite of all program code from scratch, rebuilding data structures, and migrating the data to fit. If your application was written relatively recently, or using a language that still exists even if it's an old version, your developer may be able to pick a software platform in the cloud that allows simply copying your program code and data to the new platform, whereupon it will run after applying any necessary tweaks or updates.

The process, as with any project, should be planned so that every step is validated before moving to the next one. This means doing some pre-validation by having an expert in the old and new platforms examine the code for any obvious roadblocks. Then you would perform a migration to the new server and run basic functions tests on dummy data, or, if convenient and safe, actual company data. Then, perform user acceptance testing with a pilot group, taking care to make checklists of every possible function that may be needed. This pilot group needs to be capable enough to take on the extra work of using the new application before it's live, given they will still need to perform the same work in the old system as part of their regular job tasks.

Finally, ensure all stakeholders are aware of and get input into the process, such as any business partners or customers that may have access to the application, and even anyone who might only be connected secondarily such as by receiving e-mailed reports. When rewriting applications, very often the reports get changed in format and content by direction of executives who take the opportunity to make it better in their estimation, or because the developer chose to use different transmission methods so as to leave behind old communications protocols, etc. When this happens, recipients of the reports might not receive them, or might discover that information they relied on is missing, or the format is no longer compatible with the tools they used on their end to import the data to their systems.

And, as mentioned, security must be integrated throughout the process. It is well known in the industry that searching for vulnerabilities and mitigating threats in an application after it's been deployed is far more expensive than addressing these before deployment.

P2V Migration

P2V in the cloud realm stands for "physical-to-virtual". It is a process by which your on-premises physical server is cloned to an emulated server in the cloud, called a virtual machine (VM). More specifically, the entire hard drive, including the startup program files (boot files), operating system, applications, documents, and anything else you downloaded or saved, is copied exactly into a virtual disk image, and then attached to a VM that emulates the hardware components of your existing computer. The VM can then boot up using the operating system software on the virtual disk image, and it runs inside a server on the cloud. It's kind of like a brain transplant. Everything will still be there.

One potential deal-killer for P2V migration of a server running a custom application is if the application requires a hardware license key, such as a dongle to be plugged into one of the server's USB ports. This cannot be emulated on the VM, so when the application loads and looks for the license key, it won't find it. Your application's original publisher, if they're around, may be able to offer workarounds.

Your IT manager could use one of many software tools to perform a P2V migration, but it may take several days depending on the size of your data and the speed of your Internet connection, and also considering he might have to start over if it fails due to an unexpected glitch or incompatibility. During the migration, your users would not be able to access the application or its data.

But, once done, this provides the most simple path to get out of your office and into the cloud. Users will need to be redirected to access the server in its new location, and that should be it. All their user login accounts, preference settings, and data will be there. Protecting the server with a virtual firewall will be about as easy as how your firewall protected it in the office. If it was not previously accessible via the public Internet, or if users accessed it when out of the office by using VPN, then you can set up a VPN to the VM in the cloud without much difficulty.

Long term, though, this does not address the age of your code and whether it will continue to work with your users' computers. Many applications, for example, run through a web browser and require the browser to provide certain features (such as scripting engines) which have been removed from browsers in recent years due to their being too easily exploited for infiltration. Since the major browser publishers (Google, Microsoft, Mozilla, and Apple) removed these old technologies long ago, if you have one of those applications, you've probably already worked around this, such as by continuing to use obsolete browsers (such as Internet Explorer) on obsolete computers, or simply learning to live with loss of functionality you once had. Rebuilding your application from scratch, as described above, would alleviate these problems.

If your application isn't accessed through a web browser, but runs an installable program on each user's computer, you may face similar problems, as with each new version of Microsoft Windows or Apple macOS, there is a possibility older software will no longer run. A major step in this direction occurred in 2015 when Microsoft Windows 10 left many legacy applications behind, so you may have gotten past the worst of it already.

Then again, the benefit of P2V migration is buying you that much more time and saving money for as long as your end-user nodes still work. If you were to have to rebuild the application from scratch in the cloud, and your users currently run a custom program (called the client application) to access the application and its data on your server, this would necessitate rewriting the client application, adding to the cost.

Not Migrating

Costs and risks of migration, no matter which method you use, include:

  • Down time during the migration
  • Lost productivity due to retraining
  • Data loss where tables might be accessible in the current system but subject to prohibitively expensive detailed work to migrate
  • Greater expenses after migration due to cloud service provider billing
  • Potential greater threats due to running on publicly accessible servers

Potential benefits include:

  • Better uptime overall, given power outages in the office or a glitch in the hardware on your shelf are no longer a factor
  • Better application security and features if rewritten
  • Better accessibility if your on-premises server was previously inaccessible remotely, and modern, simple methods for secure remote access to its new location in the cloud are deployed
  • Improved capability to perform backups, without relying on in-house storage media, and taking advantage of high-speed connections from your cloud hosting provider to a cloud-hosted backup provider

How long you intend to continue running your business, or whether you are planning to ditch the entire application at some point in the future and use something completely different due to the changing nature of your industry, are always fair considerations as well.

After performing analysis of the costs and risks of migration, you might find leaving things as they are is perfectly fine, which is fair and sensible if your analysis so indicates.

Other Considerations

A common concern when migrating to the cloud is what's called "vendor lock-in". That describes a situation where your application is so highly customized that moving it to another cloud service provider is prohibitively expensive. Of course, you may consider yourself there already with your on-premises server. However, avoiding lock-in speaks to performing the rewrite, rather than a P2V. A rewrite, properly planned to use modular software platforms that can be easily moved to another provider if your current one proves to have performance problems, charges unexpectedly excessively for usage, etc., would be far superior than a P2V, which simply moves your current lock-in situation from your office to a VM in the cloud.

Final Thoughts

What's best is if you have an experienced IT service provider who can assess your on-premises servers and create a migration plan with your requirements and plans. In all cases, to ensure your up-to-date on your technology, your best bet is to contact J.D. Fox Micro.