Can I get more information on migrating from self hosted to Looker hosted?

[Lesleymustari]

Knowledge Drop

If you are interested in migrating to Looker Hosted, contact your Field Sales Representative to get the process started. It takes time to collect all the information needed to have a successful migration. We are here to help!

To start out, your FSR will ask you a few questions. These will be provided to our ops team to make sure things go smoothly.

At a high level, these are the things to be thinking about:

What would you like your hostname to be? Where are the Looker Files Located? What is the current Hostname? Are you clustered? What are your host specs? Will you be hooking up a tunnel, or will you be using our allowlist IPs? How big is the Looker user directory? What is the size of your internal database? Which hosting provider? AWS or GCP? What Region? Do you want a custom domain? (this sometimes costs extra depending on your contract) We set up the custom domain first, then we perform the migration. 

Database Connectivity: You will need to decide how the Looker-hosted instance will connect to your database(s), essentially via a direct connection or SSH tunnel. In either case you will need to white list our IPs. See this doc: https://docs.looker.com/setup-and-management/enabling-secure-db

Disk Space: Your self hosted instance will need enough disk space available to temporarily store a tar.gz file of your Looker user's home directory, shared storage (if present) and a MySQL dump (if you have a MySQL backend).

Personnel and Transferring Data: You will need someone with command line access to the on-prem Looker host, who can login as the Looker user or root will need to create the tar.gz file(s) containing your home directory, shared storage (if clustered) and a MySQL dump (if you have a MySQL backend). You will need to have some way of sharing the file(s) with us. The most commonly used options include Google drive and customer hosted file share.

Things to know: The Looker-hosted URL may be different from the self hosted URL (like customer.looker.com).

For the looker directory, our DevOps needs the models, models-user-*, deploy_keys, bare-models (if applicable), and other looker generated directories, for example: custom visualizations.

After the cutover to the Looker-hosted instance, Looker will most likely rebuild ALL your PDTs. This can cause load issues on your database(s) in some cases.

The Looker-hosted instance will be kept up to date with the current Looker release, which requires short downtime each month. Make a point to find out when your release date is so you are prepared.

Downtime / Cutover:

Looker DevOps will need time to transfer the data, perform some configuration on the hosted instance, and startup Looker. The amount of downtime depends on a number of factors including the amount of data involved, if you have MySQL or not, whether we'll be clustering the hosted solution, and the exact process we'll use for the cutover.

The simplest method which also creates the most downtime is:

Customer stops their on-prem Looker, Customer creates tar.gz file(s), Customer shares file(s) with Looker Looker ops copies the file(s) to the hosted Looker(s), Looker ops starts up the hosted Looker(s), Customer verifies all is well.

To minimize end-user downtime, some customers prefer this method:

Customer stops their on-prem Looker, Customer creates tar.gz file(s), Customer starts their Looker back up and notifies their users it is available for use, but not updates, Customer shares file(s) with Looker, Looker ops copies the file(s) to the hosted Looker(s), Looker ops starts up the hosted Looker(s), Customer verifies all is well when convenient (this may take days for a thorough check), Customer shuts off their on-prem Looker and notifies their users to use the hosted Looker.

Questions on this process? Comment below.