A reader sent an email asking how long does migration take. A good migration consists of at least three passes:
- Prototype migration: the purpose is to learn the steps required for your migration. Discover and resolve unexpected issues. The outcome should be a checklist of what should happen for the migration.
- Dry Run migration: the purpose is to validate that the checklist and issues are resolved. This should go without any hitches.
- The time it takes should be recorded.
- Repeating this a few times builds confidence and reduces the risk of the unexpected.
- Actual migration: you are doing it!
Javed Iqbal sent me these estimates from the migration he is working on (excluding the wait and negotiation time with the client’s IT and Security departments). Unlike a generic migration, there is no need to move code because there is a SQL Server implementation already written — you just need to move the data.
- Setup time: 2 days
- Transfer time: For a 150 GB Oracle source database (using 4.2 version of SQL Server Migration Assistant for Oracle)
- 10 hours to move the raw table data
- 6 hours to build the indexes
- Test time: 1 day for smoke testing
- For prototype migration, you may wish to spend a week to build confidence that everything is correct.
- For dry run migration, writing some critical test scripts reduces the test time for the actual migration.
- For actual migration, executing the test scripts using a team will often reduce this time to a few hours.
Your transfer time may be significantly less if:
- You are using the Server-Side Data Migration; Javed was forced to use the slower Client-Side Data Migration.
- You are using version 5.0 of SQL Server Migration Assistant for Oracle (due for release this summer, see this post for more details)
- Version 5.0 exploits multiple cores, significantly reducing the 10 hours to move data.
The bottom line is that for most firms running Kronos, the actual migration and testing should take less than 24 hours (assuming donuts, pizza and Jolt Cola is in abundance).