We have recently completed a project for our friends at Metro - the Portland area’s regional planning agency – where we assisted them in “re-platforming” their major databases from Oracle to SQL Server. We seem to be making a habit of working with Metro when they are making big changes!
The Oracle databases were integral to many internal and public-facing web applications as well as data processing routines and desktop analysis tools used throughout Metro and by other agency partners. In other words, there was a lot on the line! As you might imagine, there was a fairly high degree of anxiety; not about any particular issue, so much as simply about the breadth of connections and dependencies that needed to be planned out, migrated, tested, and put into production.
Did we mention that we had a little over a month to plan out the approach and implement it?
Luckily, for us, the Metro team was a pleasure to work with – diligent, detail-oriented, and mission focused. They did a great job in the pre-planning even before we began our work. Our planning-phase tasks involved performing legacy database analysis and assessment, including identifying system dependencies and prioritizing the migration of databases and applications accordingly.
When we’d made it through the library of planning phase tasks, sub-tasks and sub-sub-tasks, the moment for the cutover was upon us. People from our combined teams hunkered down for a long night and proceeded step-by-step through the final maneuvers.
It all turned out to be a bit anticlimactic. Our teams were all able to head home well ahead of schedule that evening with no-need to initiate any of the much-discussed triage activities.
We like to think that wasn’t all luck.
With the migration complete, Metro (and everyone that depends upon those databases) can continue with business-as-usual, with the confidence that their systems will work as expected.
Some of the interesting tidbits
- We used Microsoft’s SQL Azure Migration Wizard that added efficiency and provided interesting if unverified metrics about how much time we saved over taking a more manual approach.
- We integrated some bench-marking processes into the migration steps so we could progressively analyze performance changes as we adapted applications and code to work with the new platform.
- We did some load testing on the new system and got a chance to throttle up and see how well it would stand the heat of simultaneous users, as well as processor-intensive operations. Identifying and resolving any potential bottlenecks ahead of implementation certainly helps with performance anxiety, of a certain kind.
- When you’re in the middle of big change, it’s a good opportunity to…make changes. We worked together to do a lot of house keeping and deferred maintenance and updating.