We recently migrated a client from Microsoft Small Business Server 2003 to Small Business Server 2011 Standard on new hardware.
We performed a migration install on the new server machine. We did the whole migration in the course of one weekend to minimize the chances of a bad outcome - data loss, email loss, business disruption, etc.
Users did not have access to the network while we were doing the migration. Email ports on the firewall were closed as well. If the migration went awry, the plan was to restore the source server from the Friday backup, without losing any mail or data.
It turned out that a "fast" migration has its challenges. Moving mailboxes from the source server to the destination server went very smoothly and fairly quickly. We moved 60 gigs of email without losing a single message in about 4 hours.
Robocopy-ing users' shared folders from the source server to the destination was a different story - copying went very slowly. We needed to copy about 300 gigs of data, but it was quickly apparent that the copying wasn't going to finish before Monday morning.
Network and cpu utilization on both machines was very low. We tried running several instances of robocopy to increase the utilization of resources and the speed of the job, but no luck. In pre-migration testing, we did not see this problem. Robocopy was reasonably quick in our sandbox environment.
We were in a bad spot. Going forward with our original migration plan and schedule was no longer an option. Rolling back to the old server was not going to look good with the client, and if we did so, it was not clear what the additional time and costs would be and who would pay them.
Winging it in the middle of a system implementation is not a best practice. On the other hand, you cannot anticipate every possible problem. So, we got a little creative while we still had time before we got to the point of no return for rolling back to the old server.
Here's what we did. Fortunately it worked. We stopped the robocopy jobs and "finished" the migration. We demoted the source server and removed it from the domain. With Exchange and Active Directory no longer running on the source server, we restarted the robocopy jobs. Then it went MUCH quicker. 300 gigs copied in about 6 hours.
Come Monday morning, the new SBS 2011 was live and in charge.
We performed a migration install on the new server machine. We did the whole migration in the course of one weekend to minimize the chances of a bad outcome - data loss, email loss, business disruption, etc.
Users did not have access to the network while we were doing the migration. Email ports on the firewall were closed as well. If the migration went awry, the plan was to restore the source server from the Friday backup, without losing any mail or data.
It turned out that a "fast" migration has its challenges. Moving mailboxes from the source server to the destination server went very smoothly and fairly quickly. We moved 60 gigs of email without losing a single message in about 4 hours.
Robocopy-ing users' shared folders from the source server to the destination was a different story - copying went very slowly. We needed to copy about 300 gigs of data, but it was quickly apparent that the copying wasn't going to finish before Monday morning.
Network and cpu utilization on both machines was very low. We tried running several instances of robocopy to increase the utilization of resources and the speed of the job, but no luck. In pre-migration testing, we did not see this problem. Robocopy was reasonably quick in our sandbox environment.
We were in a bad spot. Going forward with our original migration plan and schedule was no longer an option. Rolling back to the old server was not going to look good with the client, and if we did so, it was not clear what the additional time and costs would be and who would pay them.
Winging it in the middle of a system implementation is not a best practice. On the other hand, you cannot anticipate every possible problem. So, we got a little creative while we still had time before we got to the point of no return for rolling back to the old server.
Here's what we did. Fortunately it worked. We stopped the robocopy jobs and "finished" the migration. We demoted the source server and removed it from the domain. With Exchange and Active Directory no longer running on the source server, we restarted the robocopy jobs. Then it went MUCH quicker. 300 gigs copied in about 6 hours.
Come Monday morning, the new SBS 2011 was live and in charge.
No comments:
Post a Comment