Data Migration : Step by Step

Question

Data Migration : Step by Step

ckempste

SSCoach

Points: 17983
More actions
March 17, 2002 at 12:00 am

#158269

Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/ckempster/datamigrationoverview.asp

Chris Kempster
www.chriskempster.com
Author of "SQL Server Backup, Recovery & Troubleshooting"
Author of "SQL Server 2k for the Oracle DBA"

Viewing 5 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic. Login to reply

Howard_nyc@yahoo.com SSC Enthusiast Points: 118 More actions · Answer 1

I will have to read it for content, in greater detail, but after a second pass I can already see things I would have overlooked if I had been doing it... not a bad template / starting point

mosaic-263591 Right there with Babe Points: 727 More actions · Answer 2

A very welcome article - even for smaller migrations it will be very useful as a template.

Can you indicate at which stage you would address differences in collation order, and the requirements for login permissions of the new system?

ivan gonzalez-195804 Old Hand Points: 304 More actions · Answer 3

Well done document, it was worth my time. I will use it as guideline as such projects may evolve down the road.

Nice job!!

Mark Green SSCrazy Points: 2085 More actions · Answer 4

I think that it was a worthwhile attempt to set out procedures for a task like this. But, honestly, I found it a bit difficult to follow. Every case is different, some models evolve, other need to run to strict frameworks. I work by the evolution model myself. I take more time over it, but there are less staff involved. I am trying to summarise the main points from my view.

1. All data sources should be recorded. Either that or the original raw data should be kept.

2. All code that alters this data should be kept. In my case this is either Perl code or T-SQL code, in the form of SPROCs.

If the above is done sensibly, in both file directories and databases, why worry?

I have a few other tips.

1. Keep a log of errors that everybody has access to.

2. Name the different versions of the system that is being implemented.

3. Keep all involved through the use of email updates, one for each major new release.

4. Keep testing/using the system with real life data requests.

5. Separate the development of the user interface (in my case an Excel VBA application), the request file handling systems (Perl based) and the analytical database (MS SQL Server)

6. Enable a record of all results that have been returned to users.