On March 14 WebSolutions Technology, Inc. Undertook the task of transferring all data, everything in Microsoft Information Services, Microsoft SQL Server and MailMax from the server I had been hosting from them for the previous two years to a new server you they had recommended to me.
I had expressed my concerns as well as the importance of this transfer going smoothly to them via e-mail, and was told by their Director of Sales that WebSolutions would do testing and that a project timeline would be created to dictate the order of operations. Based on that and the fact that this new server had been configured and ordered by WebSolutions, I felt comfortable in WebSolutions' ability to pull this off, so I agreed to go ahead with the transfer.
After they took the old server offline and put the new server online, problems began to surface almost immediately. My web site did not work on the new server. They immediately took the new server offline and put the old server back online. At that point they were unable to determine the cause of the problems and told me there was nobody at WebSolutions at that time that could diagnose and repair the issue.
At their suggestion I brought in a third-party Consultant to logon to the new server to determine the cause. They determined that the new server was missing the ASP.net machine account, which should have been installed by WebSolutions when they installed ASP.net on the server. Armed with this information, they installed the ASP.net machine account and put the new server back online. Our web site was now visible on the Internet and we thought the worst was behind us.
Later that day when I tried to run my daily reports using Microsoft Reporting Services, they did not work. Once again nobody at WebSolutions was able to determine why these reports would not function on the new server when they had functioned properly on the old server. This time I had to contact Microsoft directly to figure out the cause. What the Microsoft Server Technical Support people discovered after many hours of investigation was that WebSolutions had configured Internet Information Services to use the wrong version of ASP.net. The version they should have configured IIS to use was ASP.net 1.1, just like on the old server, but they configured it to run on ASP.net 2.0.
According to Microsoft, this caused an aborted installation of Microsoft Reporting Services, and the debris' from that installation prevented subsequent uninstall/reinstall attempts.
Now that Reporting Services was working, I ran my reports on March 15. When I ran my month-to-date report, I noticed that there was no activity reporting from March 1 through March 14. I knew there had been many transactions during that period, so I ran a report for the previous month and found that all transactions were missing for the last half of February as well. Without the data that was missing, I would be unable to charge my clients at the end of the month, so it was imperative that the missing records be found.
Once again, WebSolutions had no answers for the missing records so I called on an independent Consultant again to get to the bottom of it.
The Consultant compared the database on the new server with that on the old server. What they found were records on the old server from February 21 through March 14 were never transferred over to the new server. This caused a corruption of the database due to the fact that new records were being added daily. According to the Consultant:
Resolving the missing data issues required significant effort. Simply copying the missing data was not possible. The Contractors4U database was designed for stand alone operation and was not designed for importing existing records or replication between multiple databases. The Contractors4U database makes extensive use of identity fields as keys. This means that as new data is entered into each table it is assigned the next available number in sequential order. Related information uses the auto-generated identity for records in related tables. This common industry practice works well for a single database designs but does not scale well for supporting multiple databases.
The missing data from the original server had identity values matching existing identity values, but with different data, on the production server. For example, let's say there is a customer John Doe with identity 5 in the original database who is missing from the new database. If there is no customer in the new database with identity 5 then John Doe can be copied into the new database along with all of his related records (projects etc.) without a problem. If there is a customer in the new database who has already been assigned an identiy of 5, then John Doe will need to be assigned the next identity in the sequence and all of the related records for John Doe need to have their customer id values changed from 5 to the new identity or they will point to the incorrect customer. This is the problem that Contractors4U encountered.
To fix the problem, we needed to map out the conflicting ID values for every database table, reassign mismatched ID values new values in temporary tables, map new key values to related child records and insert the new data into the production database. This is a tedious and error-prone process.
The Consultant went on to say:
It is our professional opinion that Web Solutions failed to perform a database restore as a final step before migrating to the new server and that that inaction caused data loss.in addition, the lack of a migration plan prevented the possibility of early detection of problems such as the loss of email functionality and data loss caused by the migration.
0 comments