Database migration to a different structured database

peterpjpeterpj Posts: 2 New member
Hi All,
         I am very new to this forum so my apologies if I'm in the wrong place.
What I'm trying to achieve is to migrate a database with one structure to a database with a different structure, what I mean by structure is that the individual tables have the same columns but they are in a different order. How do I go about doing this task for the whole database. The new database is completely new has no data just a different structure.
Appreciate any help or direction
Best Regards,
peterpj
Tagged:

Answers

  • Sergio RSergio R Posts: 610 Rose Gold 5
    Hi peterpj,

    If I understand correctly you want to migrate data, as opposed to the schema?

    If you are migrating data, column order is not relevant.

    SQL Data Compare can help you migrate this data.

    Kind Regards,
    Sergio
    Product Support Engineer
    Redgate Software Ltd
    Please see our Help Center for detailed guides on how to use our tools
  • peterpjpeterpj Posts: 2 New member
    Hi sergio R,
    Unfortunately due to my lack of understanding I'm not always clear. I want to completely migrate the schema and the data from one database to another which has a different structure. The target database also has tables that do not exist in the source database but maybe related to a table that both the source and the target have. The target database is far more comprehensive that the source.
    Sorry about the confusion, I hope you can point me in the right direction as to how I might achieve this.
    Best Regards,
    Peterpj
  • Sergio RSergio R Posts: 610 Rose Gold 5
    Hi Peterpj,

    All that should be possible using our tools.

    You should start by migrating the schema, you can use SQL Compare for this task.
    If you want to make the schema in the target 100% identical to the source, this should be straightforward: usually it's just a case of comparing, making sure that all objects are selected for deployment and then deploying.
    Please note that if you are using default options, a different column order in a table, by itself, will not cause SQL Compare to consider the source and target different, so if column order is important, you should enable the "Force Column Order" option in the project options.
    If you don't want to drop any tables that only exist on the target, you can do so quickly, by unticking the tables correct group in the Comparison screen:

    SQL Compare and SQL Data Compare map tables automatically using the table name, however you can override this .

    Kind Regards,
    Sergio
    Product Support Engineer
    Redgate Software Ltd
    Please see our Help Center for detailed guides on how to use our tools
  • Database migration refers to the process of moving database data and structure between systems, for various reasons such as upgrading to a different DBMS, consolidating multiple databases or adapting its structure in order to meet new requirements. Below are key steps involved with migrating from one structured database format to another:

    Assessment and Planning: Whilst creating your database plan, identify both source and target database systems by noting their names, versions, data structures, types, features, etc. between the two systems.
    Definition of Migration Goals and Objectives: Set clear objectives for why and what you expect from this move.
    Analyse the Source Database: Evaluate the existing database structure, data quality and size in order to assess potential challenges and areas for improvement.
    Create a Migration Plan: Establish an extensive plan, outlining timelines, resources required and step-by-step strategies for the migration process.

    Data Extraction:
    Extracting Data From the Source Database: To extract data from its original location without altering data integrity, utilize database-specific tools or custom scripts for data extraction from its original database source and ensure all essential tables, views and indexes are captured during exportation.

    Data Transformation:
    Convert Data Types and Structures: Adjust extracted data so it meets the structure and data types of its target database, such as by renaming tables or columns, changing types, or applying transformations.

    Schema Mapping and Creation:
    Connect source schema with target schema by mapping tables, columns, and relationships from one database to those found in another database.

    Data Loading:
    Once transformed data has been transformed and imported to its target database, use appropriate tools or scripts to insert it.

    Testing and Validation: Carry Out Data Validation:
    Check that the target database matches up with its source counterpart as per expected quality standards.

    Tuning:
    Fine Tune the New Database: As part of performance tuning, fine tune your target database as necessary - including indexing, query optimization and configuration adjustments.

    Migration Execution: @ (Execution of Migration Plan and Steps according to Timelines).

    Monitoring and Post-Migration Testing: Continuously monitor your newly migrated database for issues or performance bottlenecks post migration.
    Conduct post-migration testing: Undertake extensive post-migration testing to ensure that the new database structure meets all functional and performance criteria.

    Data Synchronization (if Required):
    If the source database remains operational after migration, establish mechanisms for ongoing data synchronization until its decommission.

    Documenting Migration Process: When taking part in any migration project, be sure to document every step taken, decisions made, and issues encountered along the way. This information can prove invaluable for future reference and troubleshooting purposes.

    Deployment and Decommissioning:Once the new database is validated and operational, transition over to it immediately while decommissioning any old databases that no longer need to exist.

    Database migration can be an arduous and resource-consuming endeavor, so it's vital that it be carefully planned and executed to avoid unnecessary downtime, data loss or disruption to business operations. You should also include backup/rollback strategies should any unexpected issues arise during migration.
Sign In or Register to comment.