Kent

I sit, here on my cushion, surrounded by empty rooms. M and I are in the middle of our latest migration - this time to Comox, BC.
I am left with my cushion, two cats and (of course), my Internet connection. "Why?", you ask? Because we're migrating our data.

It doesn't matter if you use Waterfall, the latest Agile methodology or no methodology whatsoever, at some point you will likely need to migrate data for an application. You might have overgrown your XML or Excel file, desire to move from Access or MSDE to a 'real' database, or have switched vendors. Either way, it's not a process that ensures happiness, especially if the data is "mission critical" (which is usually translated as, "This data is my Big Red Button™, please don't lose it."
"What's the big deal? you run a few DTS scripts, and restart the app, right?"
{insert laugh track here}
Data — real data, not frufru data — is valuable. It's customer records, sales records, employee records. It's the furniture in your house (you were wondering when I was going to try to merge analogies, weren't you?), it's the source code for your business (all analogies lead to programming, as all history leads to Hitler). Moving data, like moving the contents of a house should not be taken lightly, as there are too many possible errors that can occur:

• Does the business need to continue to run while the migration continues, and if so, where does that data go? (imagine migrating Amazon or eBay here)
• How much monies go missing if the data goes missing? (imagine migrating a real bank app here)
• How long will it take you to recover from backup? (imagine a nice insurance app here)

You have a few strategies that are commonly used for data migration:

• Two, parallel systems. Bring up the new database/system, and have people enter data in both during the transition. Users hate this, as it means twice the work, but it is the 'belt and suspenders' model to a 'T'. Smarter versions of this move the double entry into the system itself. You can use this time to find bugs in the new database/system, without fear of losing data.
• Cutover. Draw a line on the calendar, and tell people, "On this date at 02:19:42.085 UDT all data goes into the new system." Boom. That's it Mary, no going back. You can usually identify the DBAs that have tried this model. Bald and twitchy.
• The Big Switch. Usually this happens when a data migration is happening with an app migration (even if only version). V1.0 of the app uses the old data, v2.0 uses the new data. Clients vie for who gets to use each system (usually more want to use the old system until they find out what the new system is like from co-workers). Meanwhile, in some back cube, someone has to stitch reports together to combine data from both systems (leading to cranky DBAs).

Moving data doesn't have to be painful, it's a great time to contemplate usage patterns and refactor/normalize your data. Can you clean up a few tables? Is that really just an instance of that other thing, plus or minus a few attributes? Was reporting really slow and you need a few more views? Where's a good place for an index?
We chose to do our migration in parallel. M went up with the furniture, and I stayed behind to work, take care of the cats and prepare for the shutdown of this system. We refactored as well: M and I sold some furniture, bought a couple of other pieces, and best of all, now have something to look at out the window.

Now listening to: the rain on the deck and 10,000 miles by Juno Reactor

PS: For those who feel that I should have included a link to MSN Live Local (Local Live?) instead of Google Maps, this was what happened when I used said fine system to search for Comox: