|
|
Preparing to Move To a New Server(Page 5 of 8) The guidance on these pages assumes that the site is a recently purchased one, but the principles are just as applicable if it's your own site you're moving to a new server. Making a list and checking it twice... There are so many things that can be missed, it's worth taking the time to draw up a meticulous list of what needs to be done to keep the site ticking over smoothly after the move. Most websites have had a lot of customisation over the years where owners have added their own code, tweaked existing code, added security features, added functionality ... and much more. And, typically, they won't have documentation for all this work carried out! This is the time to get a formal document together. Keeping it updated is a good habit too, should the webmaster fall ill and/or someone else needs to take over the site in an emergency. An easy option is to just let the seller make the transfer and setup for you. If he gets stuck and something doesn't work, there's nobody in a better position than he to fix it... but this has its drawbacks. It's best to do the transfer yourself. Insist on doing the transfer yourself. Call it a deal breaker if the seller is not willing to give you all the documentation and guides required to do it yourself. Handling the nitty-gritty of the transfer is a good exercise, gets you familiar with the quirks of your new, expensive acquisition, puts you in a comfortable position should you ever have to move again or solve tech problems and is a good extension to your earlier due diligence work. It also forces the previous owner to examine and document all that's required for a new owner to setup and configure the site. So get the seller to put his thinking cap on and assist with the list. Some suggested lines of thinking (not all are applicable to every site, of
course):
For example, - What OS and server software (Apache/IIS) is needed? Does all he's listed tally with the plan you've purchased? 2. What affiliate or other codes do I need to change? Adsense
publisher IDs and other affiliate codes will eventually need to be changed to your own publisher
Can the codes be changed in a single SSI (server side include) file or the CMS, or would they need to be manually done on each page? Can this be safely done with a find and replace? What about systems in place for breakdown and tracking of earnings? For example, Adsense has channels and the seller may have channels configured to know which pages are the best performers with Adsense. You would need a list of those channels names and numbers and an explanation of what each one relates to if you wish to retain the same reporting format for comparisons. 3. What about order processing and payment facilities? If these facilities are not transferring with the site, do you have something else in place? What do you need? It's not uncommon for a site to have some of its revenue come through Clickbank and CommissionJunction while other revenue comes in through Moneybrokers, RevenueWire, DigitalRiver, IZEA, text-link brokers and others. For every revenue stream do you see a clear route to transferring the revenue to your own account with those providers? Third party payment processors, like Plimus, are great but it takes a considerable time to get familiar with their interface and set up and to configure the numerous screens on their sites. Have you got all the information you need to do this effectively before your web site starts sending orders to your account? If some of the payments are via Paypal subscription (typical for membership sites, sites charging a monthly fee for text links etc), the subscriptions can't be transferred from one account to another. How is this going to be dealt with? 4. What's needed to transfer the mailing list? If the seller has a subscriber list using a company such as Aweber then check that the list can be transferred to your account. Aweber, the last I heard, do allow such transfer on payment of a fee. Others don't. 5. What software licences do you need? Licences for the CMS, forum or other software on the site may need to be transferred to your name if you wish to continue to use them legally and have access to bug fixes and upgrades. 6. If the site has affiliates, how are they managed? If it's a third party application then can control be handed over to you or will you lose all the affiliates who are driving the sales? 7. What about agreements with merchants or drop-shippers? Will they transfer their agreements to you and what needs to be done to effect the change? 8. How do I backup the site? If you create a backup of the website using the control panel at the old host, you may be able to move that backup file to your new host and use the control panel to restore all the settings and files for the website in a single step. 9. What control panel is used to manage the site? Most websites depend on a web hosting control panel to make the job of managing the website easier. A control panel will handle website backups, database setup and maintenance, access control, webserver settings and other important but mundane tasks related to maintaining the site. The most common control panels are cPanel, Plesk, and H-Sphere, DirectAdmin, and Webmin, with cPanel being the most common. If the website is currently using a control panel, it would be wise to use the same control panel at your new host to avoid any compatibility issues when moving the site. etc. Each site is individual and there can be no comprehensive list of questions that covers every situation. A large dose of common sense combined with careful analysis of current features and operations directs what will eventually end up on your list of questions. While working on the list it may be helpful to create for yourself a note of what checks you intend to do on the transferred site to test it's fully working. Backing up the site The entire site needs to be backed up following the instructions you compiled at (8) above. Some files can just be downloaded to your PC via FTP (see next page) or the seller can send you a zipped version of the entire website. But the treatment of databases is trickier. You may need to temporarily shutdown any forum, blog, wiki or other function that calls on the database to prevent corruption while backing up and to ensure no posts are missed between backup and reinstating. Then, if it's relatively small, you can download the database just like you would a normal file (or get it zipped). Large sites and large databases - some comprising many GB of data - can be transferred directly from one hosting company to another using SSH. Details are on the next page but this method is a bit more technically challenging. It also suffers from the disadvantage of you not ending up with a backup on your own hard disk.
|
