Last but not least, to conclude our blog series, we’ll delve into Server (Domain & Hosting) Migration. Since we already scoped Technology Migration and Database Migration as key elements of the backend migration process, it only makes sense to finalize with server migration.
Generally speaking, migrating your website from one host to another might be easier when compared to the other migration types we discussed previously. In practice, it can be likened to giving a new address to your website. The rest of this article will explain the key facets and the best practices related to this migration vertical in great detail. So, without further ado, let’s jump in!
What is Server migration?
In the most elementary sense, Server migration is a migration technique in which data is positioned from one server to another. It basically entails configuring a target server to replace an existing one by copying over websites and their configurations and changing DNS to direct visitors to a new server. Server migrations are common in many data-dependent businesses, and due to the sensitive nature of data, deliberate planning is highly imperative for a successful migration.
Why Server migration?
Server migration can occur for different reasons, such as:
To handle increased traffic.
The desire for better performance and faster response times.
The desire for improved control, manageability, and flexibility.
Though on the other end, there are individuals who downgrade to low-end servers for cost-reduction purposes. Server migration also involves two key aspects, namely; domain migration and hosting server migration. For the bulk of this blog, we’ll explore both categories. For instance, the difference between switching hosting providers (such as GoDaddy to AWS)and transferring domain names (for instance, example.com to example.info).
What is Domain name migration?
Domain migration in simple terms means moving a website from one domain name (example.co) to another (example.info), without data security loss or impairment. Principally, when transferring a domain name, then you don’t require a backup since there will be no file transfer between servers. Although DNS (Domain Name System) information must be transferred as a requisite to have a record of the change. Protocol change may also take place when a non-secure website is moved to a secure website, like when an HTTP website is moved to HTTPS. Basically, reasons for changing domain names differ, for example, it could be a choice to move from a generic domain like .com to a more geographically specific one like .in or .cn.
What is hosting server migration?
Hosting Server Migration means basically moving from one hosting service provider to another. When you are migrating, you will need to institute a full backup of your website along with the database files on your device before initiating the migration process. Also, be sure that all your server-side scripting can be installed on your new hosting platform and that your website can run smoothly on the new server. There can be multiple reasons to migrate from one host provider to another:
The desire to take advantage of the new technology stack or better service
Application Server Migration: This basically entails transferring a software application from one server environment to another. This basically happens every time files are moved between servers.
Mail Server Migration: Here data is channeled between email server migrations within the same or different hosts.
Virtual Server Migration – This migration domain involves virtual servers or transferring a virtual machine from one server to another. There are multiple server options available in the market like GoDaddy, AWS, DigitalOcean, Alibaba Cloud, etc. However, choosing one largely depends on the project’s requirements. There is one common rule that applies to every hosting server migration– you can change hosting servers only if you have been registered with the previous domain registrar for 60 days or more. You can learn about other rules that are available from on the respective hosting sites.
How to migrate your domain name?
Domain name migration is more readily deducible in contrast to server migration. The most common reason cited to migrate domain names is that users might have a longer domain name and want a better and shorter version of it. However, before switching domain names, there are mainly two different scenarios to keep in mind:
Buying a domain name that has already been used by someone else: This can be an expired domain name that you must have purchased at a domain auction or directly from someone else.
Purchasing a completely new domain name that has never been used before.
Let us take an example to understand the difference between the above two scenarios, and why they’re imperative. If you are intending to purchase a previously registered domain name, then there are chances that you could face any of the following problems:
It may have links pointing to it which may be good or in some cases, bad for your site.
It is possible that it was previously attached to an off-topic site that was made for a different purpose than yours.
You may be penalized or banned from some of the search engines.
The domain name migration process is fairly simple. Just follow simple steps and you will be done in no time.
To begin with, you will need to verify every version (that is http://, http://www, https://, or https://www) of each site on the google search console. Also, identify all the sub-domains, if any.
Crawl the entire site. You can use different tools available online for this purpose. This will help you identify all the possible URLs, and makes a list of them. You will need it later.
Using 301 Permanent Redirects, redirect from the old domain name to the new domain name.
Test the redirects to make sure that you are not redirecting multiple times. It may confuse users.
To tell Google that you are moving to a new domain, use the Google Change of Address Tool. This will help you confirm if the redirects are set up properly or not.
Don’t forget to update the settings in Google Analytics to point to the new domain name. You can edit the Google Analytics settings if you want to keep old data in Google Analytics.
Use the list of URLs you created to crawl the site again, to ensure that all the old URLs are redirecting to new URLs properly.
How to migrate from one service provider to another?
As hinted earlier, server migration is really straightforward. Websites typically face some downtime during the server migration process, no matter how well-planned the migration process is. So, a migration plan must be prepared well in advance before executing the migration process.
Generally, one must execute the migration process when you have the least traffic on the server. You need to move according to the plan otherwise, there is a good chance that the hosting server migration process may face failure.
After you’ve settled for a hosting provider, purchase a plan, and get ready to move your website to a new host. Make sure that the plan from the old domain registrar is not canceled until your website is completely migrated to a new one.
There are some precautions you need to take care of before proceeding with a migration like taking a backup of all your database and website files from your old domain registrar.
You can import your database using PHPAdmin or some other third-party software. Then, upload your website files and database to the new server of your domain registrar.
Make sure that you install web apps on a new server first before uploading your database then export the database from PHPAdmin or some other third-party software where you back up the data.
Remember to add all the email accounts to the new server before switching the DNS. You can also create a “catchall” address to ensure that no mail would bounce in case if you forget to add any email address.
As a best practice, you can create two accounts for each email address, then use the IP address of each mail server in POP settings instead of the domain name. With the help of this practice, you will not miss any emails during the DNS propagation method.
Once all your website files are on your new hosting server, you will need to perform a series of tests to ensure that all images, texts, and links are in the proper place and function properly on the new server.
When changing the DNS records, you need to change the DNS record from your control panel with the domain registrar. Essentially, you’ll have to change the domain name servers to the ones in the welcome mail that were sent to you by your new host. Within two to four days, the migration process will be successfully completed.
Lastly, don’t forget to cancel your hosting account from your old hosting service provider.
Preliminary Pointers to Consider to Achieve Seamless Hosting-Server Migration.
Verify that your hosting platform on the source server is supported for migration:
Carefully choose a suitable target server and the hardware for the destination server. There are differences in application, for example, whether you transfer your data from one dedicated server to another; or whether the new server structure is based on clusters that involve several disparate systems.
Choose a supported operated system for the destination server
Choose an executable method to bring domains online on the destination server after the migration (for example, migration to new IP addresses and updating domains’ DNS records after migration to point to them). If the source server is overloaded or is low on resources it is better to plan the migration job outside of business hours if possible.
Ensure that all available components which are in use on the source server are installed and configured on the target server as well.
Make sure there is sufficient disc space on the source and destination servers
Add the necessary amount of IP addresses on the destination server (the best practice is to have an equal amount of shared and dedicated IPs on both servers for migration).
Testing Phase Considerations
End-to-end performance testing is recommended to gauge potential risk. During this time, trial some low-risk applications, perform some development tests, and then work your way up to higher-risk applications. Such an incremental process allows you to gradually build confidence in the process whilst testing bigger and more complex applications.
Notwithstanding, post-deployment is as important and servers should stay in a fairly ‘intensive care’ state post-migration.
The risk of intermittent unavailability. This invariably spells trouble for business operations and can lead to forced downtime just to fix the issues.
In essence, the most effective way to mitigate such risks is to plan fully approach migration. This involves carefully taking stock of key applications and data stores, as well as instating contingencies like creating reliable backups for critical applications. For instance, some companies stage a migration simulation (with cloud simulation tools) to identify other potential issues they might encounter with a sophisticated migration.
Choosing a backup method
Without sounding like a broken record, I cannot emphasize enough how important backups are! Inherently, the best backup approach is to create an image backup of your disks. Generally, an image backup deeply captures critical information, including registry keys, license keys, settings, and application-specific data.
Furthermore, Image backups allow for the conversion of a physical server backup to a virtual machine (VM). In essence, this conversion keeps a copy of the original machine that can be spun up anytime later, if one needs to access old system data. That being said, image backups deliver a crucial safety net for the migration process
On the other hand, a file-based backup approach is also a workable alternative. However, because file-based backups operate on a level of a file system when you’re required to back up a whole operating system or a virtual machine, the file-based backup might not be sufficient.
It’s noteworthy that during this process, one should not decompress any of the downloaded backup files because this process will be completed by the new server.
Have a Rollback Plan
A rollback strategy is a fail-safe if something goes terribly wrong or if there are overwhelming multiple issues. It basically allows you to revert the changes and return your servers to their original state, pre-migration.
Ensure that your service providers have such measures in place.
Our Server Migration Checklist
Based on what we have detailed today, let’s summarise the most important questions to ask when initiating or contemplating a server migration.
Which architecture should the new server have, and does the project’s architecture suit your needs?
Are there sufficient financial resources and specialists available for the migration exercise and the subsequent server configuration?
Is the selected hardware flexible enough for the future development of the project?
Should the migration process occur whilst the system is still in operation, or should all activities be interrupted for the duration of the process?
Is the possibility of maintaining operations proportionate to the availability of resources and the increased complexity of the migration?
If so, which steps can be taken to keep the downtime as low as possible?
How will you ensure the integrity of the database entries and that they are up-to-date?
How will the functionality of the new server be tested?
What happens when certain applications do not work after data migration is complete? What contingencies or workarounds can be instituted?
I hope this blog gives a comprehensive idea and details the differences between domain migration and hosting server migration. Migration is a much wider topic but I have tried to cover all the important aspects that could help you make a decision when kick-starting your migration journey.
This series of blogs will essentially help you define the scope of migration, avoid scope creeps, choose a technology stack wisely, and understand the intricacies behind the different types of migration like Technology Migration, Database Migration, and Domain & Hosting Server Migration. The purpose of this blog series was to ensure that the readers would not have to search and migrate through scattered websites on google to learn about migration and other details of the migration. Hope you found this blog series useful! For any questions on how to achieve an effortless migration, kindly reach out to us here at Creole Studios.