How to convert old data to a new system? using sql or managed code?

Let say a company are building a brand new application. The application are following the DDD principles. The old codebase has alot of products (or another "entity" for the company) that they want to convert to the new codebase.

How should this work be done? normally it is faster and easier to import using for examples ssis,-transferring from one database to another. But the main problem here is that alot of the BusinessRules (implemented in managed code in the DomainLayer) is skipped... Is this good enough if the develeoper says: "i have it under control. The rules are duplicated as sql scripts..."

Should we import the managed code libraries into the SQL Server (atleast this is possible in .NET and MS SQL Server)? Or should we we create a import script in managed code so all the layers in the domain are traversed when the entity are saved in the database?... (can take many hours..)

What are your thoughts?

From stackoverflow

• I would suggest that you write a little - import-application in .NET where you can apply the business rules. Since this task (at least I suppose so) will only run once (or twice ;)) speed is not that important - for speeding it up - design it to be multi-threaded - if possible.

  and no it is not good enough - if anyone says "I have it under control" - this is a buzz-sentence and all my alarm-bells go off. some detail will always be forgotten and this is mostly a little catastrophe ;)

  ThorHalvor : tnx for the answer. I agree with you, but i see people/developers start using ssis for these purposes, not thinking of all the complex business-rules...(rules that sometims did not exist when the import-convert-project started, but are added later in a paralell project..)

  Gambrinus : I'm currently working on such a project - SSIS import & import-app because the translation-logic from the old-db to the new-db was to complex to put it into a SSIS-task (unfortunately)

• The two options are not mutually exclusive. SQL Server can consume web services. You can create your import service as a web service and then call it from SQL Server. You can, of course, even do this with SSIS.

• Like a lot of other questions in that league (which is the best approach for this and that, which language to choose, ORM or not) it is hard to answer without knowing about the details of the old app, the new app, the data model (relational and OO).... Or easy: Analyze your task carefully and then choose your tool.

  • Will the new app be build on top of the new relational layer with it's own also new domain layer or will the mentioned domain layer stay?
  • What kind of and how many business rules we're talking about?
  • ...?

  Without knowing too much about all this I'd say: The new app has to follow the old business rules as well as the new relational layer has to be designed for the domain. The developers should by that know about business and domain rules and the (sql-)scripting should be a viable way.