Update – Aug 5, 2015 – We discovered that the sync server wasn’t running, so you weren’t able to sync your user data even after the DNS changes propagated. This has been fixed. If you had trouble synchronizing your notes, highlights, and bookmarks, try again.
This article will mean very little to most of you but some of you might find it slightly interesting.
I don’t like to get off a perfectly good horse midstream. Windows Server 2003 and SQL Server 2000 have been serving us well for a very long time. But Microsoft discontinued support for Windows Server 2003 last month and that means no more security updates. As a result, our next PCI security scan was doomed to fail, which doesn’t mean your personal data would be at risk (any more than passing the PCI scan protects the data), but it doesn’t make for good PR.
(PCI is the Payment Card Industry and the scan is required to meet their card security standards. Laridian doesn’t store your card data so the requirements for us are pretty light. You’re at significantly more risk when you hand your card to the clerk at Target, and we all know from experience that even though they passed all the security scans it didn’t do them much good.)
Upgrading to Windows Server 2012 and SQL Server 2012 meant physically moving the contents of our servers to new hardware, and as long as we were doing that, we decided to shop around for better pricing. We found it at SingleHop.com, which offers the type of dedicated server solutions that we need. And they do it for half the price of the company we had previously been with.
Laridian maintains several large databases. These contain your customer account, your transaction history, all the user-created data you’ve sync’ed to the Laridian Cloud, and the downloadable files that make up our books and Bibles. In addition to those we have a couple others for in-house purposes. Because SQL Server 2000 is past end-of-life, those databases could not be imported directly into SQL Server 2012. We had to first import them into a SQL Server 2008 instance, then import that to SQL Server 2012. The good news was that having done that, the databases functioned exactly the same. In fact, we were able to simply point the old website to the new database, and it would work just fine.
Let me pause for a minute to say this: We cannot build PocketBible 1.0.0 for iOS anymore. Not only would the resulting program not even come close to working on iOS 8, it would fail in the compilation and linking process. PocketBible 1.0.0 was released in September 2009, just six years ago.
Contrast that with the code that runs on our website. In 1998, we contracted with Jomax Technologies — Bob Parsons first Internet company, before he founded GoDaddy — to create our e-commerce site. There is a significant amount of code dating from 1998 still running on our site, especially on our back office site, which is where we generate sales reports, create new product pages, and define priority codes. This code is running unaltered seventeen years later, accessing a database that has been in continuous use for all those years.
When you hear me complaining about the unnecessarily rapid pace of development from Apple (and other companies who drive our industry) and how they create problems due to their lack of regression testing and backwards compatibility, this is what I’m talking about. Because Microsoft knows it would be a huge problem to break millions of websites, they go out of their way to continue to support the technologies on which the internet is built.
But I digress…
This move took place over about a four-week period. (I actually thought it would take twice that long.) The first step was to move the system we use for source code archival (SourceGear Vault). This was necessary because we use Vault to maintain the website. We check code out of Vault, make our changes, and check it back in. Vault populates the website folders from the files we check in. It would be most convenient if we could continue to do this the same way on the new website.
Because we were running Windows Server 2003, we couldn’t upgrade to the latest version of Vault, which requires Windows Server 2008. And because we were running such an old version of Vault (version 5) we couldn’t upgrade to the latest (version 8) directly. We had to first upgrade to version 6, which upgraded our database, then upgrade to version 8, which upgraded it again. With Vault working on the new server, we were able to move software development and book production to the new server within about two weeks.
Prior to moving Vault we had captured a snapshot of the websites and databases and were running those on the new server for testing. This allowed us to do a quick test to verify that the Web pages themselves would run under Windows Server 2012 and IIS 8. They worked just fine.
Next, we knew that during the transition to the new site there would be a period of time while DNS changes were propagating during which we would have to access the new database from the old website. We ran some tests that verified this would work.
Last, we had to build the Laridian Sync Server Service code with Visual Studio 2015 and verify it worked. It did.
At this point we spent a couple days locking down the firewall settings. We had a period of just a few hours when we had an open SMTP (email) server that was exposed to the outside world. I was shocked by how quickly the spammers discovered it (by literally rifling through IP addresses and sniffing for servers). We worked with SingleHop to quickly lock that down.
Now we just needed a procedure to follow for getting a final copy of the database moved to the new host. The problem was that we couldn’t be writing to it while it was being moved, which meant shutting down all commerce, account updates, product registration, and user-data synchronization for some unknown period of time. SingleHop estimated two hours to move the database, but suggested we allow three. I allowed four. (It took five.)
Once we knew what needed to be done, we picked a convenient date and time to do it. We were able to configure much of the code to just shut itself down at 8AM CDT the day of the migration. So, for example, the code to do synchronization of user data from PocketBible for Windows would still be there waiting for connections, but starting at 8AM (7:30, actually) it would return an error code to the client saying that the site was down for maintenance. By automating that process, it meant there were fewer manual actions that needed to be taken in the moments before the migration began. In fact, by the night before the move we were down to where it would take only ten check boxes and about 3-4 button clicks to completely bring Laridian to a stop for the two, three, or four (or five) hours it would take to move the database.
The morning of the move, I discovered SingleHop had left themselves logged into a server, which blocked me from getting in to click on two of my ten check boxes. I asked them to do that for me, which was not a problem. Then I discovered that the person who I was told would be doing the migration hadn’t been told about that fact until 30 minutes after the migration was to have begun. He was rousted out of bed or wherever he was, and started moving the databases.
With that small hurdle overcome, and with the website having automatically stopped processing new transactions to the database, I was able to get in and make three lines of code changes that it took to point the old website to the new database server. That was really all I needed to do during the time while the database was being exported from SQL 2000, imported to SQL 2008, exported from SQL 2008, and imported into SQL 2012.
The last step of the move was to make the DNS changes required to point everyone to the new server. It was at this moment that our registrar (GoDaddy) decided to make buggy changes to their website that kept us from changing our zone file. After two or three hours of attempts, we were finally able to get those changes made.
In the end the move turned out to be easier than I thought and was significantly less time-consuming than I had anticipated. I’m sure we’ll discover small things that are broken, but the major functionality of the new servers appears to be working.
Thank you for your patience during the move.