![[Valid RSS]](/media/images/valid-rss.png "Validate my RSS feed"){kind=small}
Back in February of this year (2005) Digital Positions decided it was time to find a new hosting partner for our clients’ websites. This decision was talked about a lot in the months preceding but it wasn’t till February that we actually sat down and started to plan the migration and search for a host.
The search for a host wasn’t a big to-do; we decided to use a company we’ve worked with in the past, who have shown they are competent hosts with values similar to ours. The company we choose was CFXHosting based in Louisville, Kentucky . Our rep Mark Click was a very personable man who didn’t come off with that whole salesman mentality, which was very nice.
So now that we had a host, we had to move all our hosted clients to the new setup. We have just under a hundred hosted clients, many of which are constantly updating their sites, or encountering heavy loads of traffic (millions of visits). So we had a few goals we set initially:
Armed with these goals and with a massive set of tasks ahead of us, I began the planning of the migration. The first thing we had to tackle was to figure out how we would ensure our clients’ data would stay in sync while we switched between our old host and CFXHosting. We explored replication of databases, automated DTS packages which would update the data nightly etc but in the end we decided we would just point our clients to the database server at the new host and if the connection was good we’d run with it.
Once we had the database figured out (at least in theory), we had to figure out how to get all the clients files from one host to the other and make sure the files stayed in sync while their domains were propagating to the new IP addresses. Our first inclination was to use RoboCopy off the MS Administrators CD but initial testing showed this program to be too slow and difficult to monitor on the scale we were going to use it. It would have been (and has been) great for a single site or a few small sites but an entire system was just too much for it to handle. I then set out to find a software program which would allow us to sync the systems and monitor the progress of these syncs. We had to ensure we could sync entire disks as well as one off directories. After much searching and many, many, many trial versions later I settled on Beyond Compare®, from Scooter Software.
Once we figured out what we would use to sync the systems, we had to figure out how. We’ve had VPN at our office now for a few months and I’ve found it to be a life saver for those times I need to be at the office, even though I’m at home or elsewhere. So I wanted to see if we could do this between our hosting companies as well. I called up the CFXHosting Tech Support line and talked to one of the engineers about setting up a temporary VPN tunnel between the two systems. Since the new servers would be running Windows 2003 this wasn’t a problem at all. So with the VPN setup it was time to begin the actual migration.
Since 99% of our clients run our custom Content Management System (CMS), i3SiteTools and since 80% or more of their content is stored in our database system this was the most crucial part of the migration. We decided early on it would be great if we could just setup the databases at the new host and point our clients to the new database server while keeping their files at the old host. We had two valid concerns with this setup.
In order to test this we started with a small handful of clients with a varying degree of traffic and database interaction. Initial tests showed a slight lag in initial page load times but subsequent page loads were acceptable and write tests seemed very responsive. It became very obvious to us that network connectivity was going to be a very small problem if one at all. So we began the process of moving the databases from our old host to CFXHosting and pointing the data sources to the new servers. Our clients only encountered a brief outage (30 – 60 seconds) while we copied their files between the systems and pointed to the new system.
Once we had all our clients writing and reading data from CFXHosting, it was time to begin the file system migration and sync. While this step was as important as the databases migration it wasn’t as big of an issue. You see i3SiteTools, our content management system, generates pages on the fly and has very little interaction with the file system. So a user would be able to make radical changes to their site without having to change the files underneath. There were only a few areas on each site which could cause us headaches and most of these were centralized enough to not be a problem.
To synchronize the files we setup Beyond Compare on one of the old hosts’ servers and connected via VPN to our CFXHosting servers. Our only concern was to sync the files to CFXHosting from our old host, and not vice versa. We started the initial sync on our servers on Friday evening and monitored it all weekend long. By Monday afternoon it was obvious we had a lot of data and it was not going quickly at all.
We stopped the synchronization on Monday afternoon and began looking at the file system on our old host to find ways to clean it up a bit. We had been with the old host for a number of years and during this time the servers had accumulated a lot of orphan files. Most of these were old zip files we used to move data between our development shop and the live servers, but there were also a number of test files and miscellaneous stuff. All of it was important at the time, but as time passed they should have been cleaned off. So I began the long task of finding these “little extras” and removing them. When I was done we had reduced our file system size by about 20%, which seems like a lot but we could do better. We then started to look even deeper at the file system and soon discovered we had a lot of traffic reports uploaded for our clients which were taking up a ton of data as well. We got approval from the higher ups to thin these reports out (archiving them locally for clients to retrieve). Once we had completed thinning out these reports and a few other minor housekeeping tasks, I was happy to see we had reduced our overall file system by 60%! There was still a ton of data on each of the servers but it was a lot more manageable now.
With our smaller file system foot print we began the synchronization process again. The first initial sync took about 80 hours to complete, but subsequent synchronizations were completed in 5 – 45 minutes depending on the size of the site.
Once we had the systems mirrored and were confident everything was moved over, we setup temporary domains on the CFXHosting servers so we could test the sites and make sure things ran properly. After a few bug fixes here and there we were ready to have our clients point their domains to the new servers. Over the next week sites went from pointing at the old host to the new CFXHosting servers. There where a few coding glitches here and there but none of them were issues which caused our clients to be down. Most of the issues we ran into were with business processes we were not familiar with, or with systems we couldn’t test until we had live data.
It’s been 2 weeks now and we are happily humming along on our new host. The clients’ websites appear to be more responsive and thanks to some extra services provided by the new host we are offering some cool new stuff to our clients. All in all this migration was a huge success and wasn’t the big ordeal it could have been. Thanks to diligent planning and testing, things went very smooth.
Comments (0)