Transitioning from Ursa Cloud to Hybrid Cloud

Overview

Ursa Studio offers a flexible deployment model, allowing it to be managed by Ursa, by the customer, or by a "hybrid" approach in which the (1) customer database and (2) S3 buckets (or Azure Storage Containers) are managed by the customer but the (3) Ursa Studio application and the (4) application database are managed by Ursa.

A common evolution of the hosting regime is for the deployment to start out in the "Ursa Cloud" but to migrate to a "Hybrid Cloud" once the customer is ready to take on the management of the customer database and the storage buckets/containers.

Happily, this transition is an easy one to accomplish, requiring only a modest amount of maintenance downtime.

Limitations

The Ursa Cloud to Hybrid Cloud transition as outlined in this document is only possible if the customer database is going to remain in the same cloud (AWS vs Azure) and in the same region as the existing customer database.

If moving to a new region is necessary, then the transition should be thought of as a new deployment, although we can use module submission and import to migrate all the existing assets into the new deployment.

Database Considerations

If the new database is managed by AWS (e.g. Redshift or RDS) or Amazon (e.g. Synapse or MSSQL) then the steps outlined in the Within-AWS Hybrid Cloud Setup document or the Within-Azure Hybrid Cloud Setup document, respectively. Customers moving to a Snowflake deployment should follow the Snowflake Installation Instructions document.

Executing the Transition

Once the new customer database and storage buckets/containers are provisioned and the appropriate access has been granted to the Ursa Studio application, Ursa staff can re-point the application at the new database. This can be theoretically done without any downtime, but we nevertheless schedule a maintenance window to resolve any possible connectivity or authorization issues.

If there are any barriers that cannot be resolved by the combined teams during the maintenance window, Ursa Studio can be pointed back at the existing database to preserve business continuity.

Migrating Data

The vast majority of the metadata that powers Ursa Studio is kept in the application database. That's why the transition to Hybrid Cloud is comparatively straightforward, because the application database will stay where it is, under the management of Ursa.

This means that once the application is pointed at the new customer database and the import objects are pointed at the new source data, running a full ELT will entirely rehydrate the customer database, as it had looked in the Ursa Cloud deployment.

That said, there are several tables of application metadata in the customer database that might merit migration. This migration should happen after the transition effort in which these tables are created by Ursa Studio; only the data within the tables need migration.

• Value Sets and Lookup Tables ( mi_aa_002 and mi_aa_003) can be migrated via module submission and import, which is the way that we recommend moving these assets into the new customer database.
• Affiliations ( mi_aa_005 and mi_aa_007) are rarely used, but you should check these screens in Metadata Manager to confirm that there are none to migrate.
• Sources ( mi_aa_012) will typically need to be recreated via the screen in Integration Manager.
• Cohorts ( mi_aa_016) will have to be migrated if you want to keep this data.