Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

Data Migration : Step by Step Expand / Collapse
Author
Message
Posted Sunday, March 17, 2002 12:00 AM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Tuesday, July 31, 2007 8:20 AM
Points: 885, Visits: 1
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"
Post #3066
Posted Friday, March 25, 2005 7:05 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Monday, April 11, 2005 2:44 PM
Points: 4, Visits: 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


Post #170221
Posted Monday, November 28, 2005 6:23 AM
SSC-Addicted

SSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-AddictedSSC-Addicted

Group: General Forum Members
Last Login: Wednesday, July 17, 2013 3:18 AM
Points: 419, Visits: 559

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?

Post #239915
Posted Monday, November 28, 2005 7:08 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Wednesday, February 8, 2006 5:36 AM
Points: 52, Visits: 1

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

Nice job!! 

Post #239930
Posted Monday, November 27, 2006 9:47 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Monday, June 11, 2007 7:09 AM
Points: 131, Visits: 1

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.

 

 

Post #325702
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse