112
Views
1
Comments
Advice around Outsystems platform migration
Application Type
Reactive, Service

Hi.

I have a service and a reactive app, which is in use 24/7 by UK hospitals.

I'm planning a migration from Outsystem Ireland data centre, to the London centre, for upcoming compliance reasons.

I currently have both environments running. My apps are installed on both, and I've tested the data migration using DMM, which has worked beautifully.

I now need to plan the go-live of the actual transfer. I'm just interested in general advice, pointers, things to look out for etc, from people who've done the same, so that I can learn from your mistakes!

Is there anything particular to be aware of, check etc?

My intent is to

  1. Stop user access to the old environment
  2. Complete the data migration (should take just ten minutes or so)
  3. Update DNS of secure endpoint(s) to point to new environment. The apps will already be enabled, so users can access it immediately.

When I've done this sort of thing before, the domains point to the old environments/sites for much longer than I anticipate, and well beyond the realistic propogation time of DNS. How can I mitigate this, so that users get pointed to the new environment immediately? I use cloudflare for the DNS management.

Thank you

2024-01-20 14-53-12
Ahmed Essawy

Migrating an OutSystems environment, especially for a critical service like one used by hospitals, requires meticulous planning and execution. You've outlined a good basic plan, but let's delve into some specifics and potential pitfalls to watch out for:

  • Pre-Migration Checks:

    • Health Check: Ensure both the old and new environments are fully operational and healthy before starting the migration.
    • Backup: Perform a complete backup of your applications and data in the current environment. This is crucial for disaster recovery.
    • User Notification: Inform all users about the planned downtime and migration well in advance.
  • Data Migration:

    • Since you've successfully tested data migration with DMM, ensure that you have a clear, step-by-step process documented for the actual migration.
    • Consider the possibility of data changes in the old environment during the migration process. Plan for a final data sync just before the switch.
  • DNS Update and Propagation:

    • TTL Settings: Before the migration, reduce the Time To Live (TTL) settings for your DNS records to as low as possible. This will help in faster propagation when you change the DNS records.
    • Monitoring: Use tools to monitor DNS propagation globally. This way, you can track how quickly the DNS changes are being picked up.
    • Cloudflare Settings: Check Cloudflare’s caching settings. Ensure that it doesn’t cache the old environment’s IP address for longer than necessary.
  • User Access Management:

    • Implement a controlled shutdown of user access to the old environment. Ensure that no new transactions or data entries are happening during the migration.
  • Post-Migration Validation:

    • As soon as the new environment is live, perform thorough testing to confirm everything is working as expected.
    • Have a rollback plan ready in case you encounter unexpected issues.
  • Contingency and Support:

    • Have a contingency plan in case of unforeseen issues.
    • Ensure that your team is available for immediate support during and after the migration.
  • Post-Migration Cleanup:

    • After a successful migration and once you're confident that everything is stable, decommission the old environment.

Remember, while DNS changes can propagate quickly, they can sometimes take longer than anticipated due to various factors beyond your control. By lowering TTL values and closely monitoring the situation, you can mitigate this to an extent. Always have a communication channel open with your users to update them on the status of the migration.


Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.