Migration from Sybase ASE to CloudSQL (PostgreSQL)

[fbermeoq]

Hi All

I need a guidance  with recommendations, tips and migration tools to assess a Sybase database with 300 GB and then to execute a full migration to CloudSQL (PostgreSQL). If you worked on a similar migration scenery, please  buddies share me your experience.

[ms4446 · Accepted solution]

Here are some general steps, along with specific tips and tools, to help you with migrating your Sybase database to Google Cloud SQL PostgreSQL:

1. Assessment: This is the initial step where you evaluate the existing Sybase database. This includes:

• Analyzing schema, data, stored procedures, functions, triggers, views, etc.
• Identifying any potential issues that might arise during migration.
• Analyzing the application or applications that interact with the database to understand how they use it.
• Determining the size of the database and the amount of data to be migrated.
• Checking for any proprietary features or data types used in Sybase that may not be directly supported in PostgreSQL.

2. Schema Migration: Once you've assessed your database, the next step is to migrate the database schema:

• Third Party Tools like the Ispirer can be used to convert your Sybase schema to a PostgreSQL compatible schema. This tool also provides a report highlighting any manual changes you might need to make.
• It's important to validate the converted schema in PostgreSQL to make sure it's correct and functional.

3. Data Migration: After schema migration, the next step is to migrate your data:

• You can use a third-party tool like Striim to migrate the data.
• Consider using a method that allows for minimal downtime. This often involves creating a full initial copy of the data, then continuously synchronizing any changes until you're ready to switch over to the new database.

4. Stored Procedures, Functions, and Triggers Migration: The migration of stored procedures, functions, and triggers could be challenging due to differences in syntax and functionality between Sybase and PostgreSQL:

• The Ispirer tool can also be used for converting these database objects, but it might not be able to convert everything.
• Some conversion will likely need to be done manually.

5. Testing: After the migration, it's important to thoroughly test the new system:

• Test the migrated schema, data, and database objects for correctness.
• Test the performance of the database and the applications that use it.
• Test the failover and recovery mechanisms of the new database.

6. Cut Over: Once testing is done, plan and execute the cut over to the new system:

• This involves switching your applications to use the new CloudSQL PostgreSQL database.
• Monitor the system closely after the cut over to catch and resolve any issues quickly.

7. Post-Migration: After the migration, there are several things you should do:

• Review and optimize your database configuration and queries for better performance in CloudSQL PostgreSQL.
• Implement monitoring and set up alerts to track the health and performance of your PostgreSQL database in Google Cloud SQL.
• Consider setting up replication or backups to protect your data.

Remember, database migration can be a complex, especially for large databases. It's important to thoroughly plan and test your migration, and to consider hiring experts if needed. Also, always have a rollback plan in case things don't go as expected.

Google's professional services or a Google Cloud partner might be able to assist with the migration. You may also want to consider attending training or hiring a certified professional with experience in this type of migration.