FAQs

Cloud Migration
How can latency between user machines and the cloud be minimized to make GIS in the cloud usable?

Latency, not to be confused with bandwidth, is a known factor since distance is key to determining latency – no matter how fast a connection, data must still physically travel the distance from cloud to machine and is constrained by the laws of physics 🙂 With this in mind, we can reduce the travel time by staying in one availability zone. Most of the clients we work with actually realize better performance after migrating to the cloud.

How is migration load handled in the cloud?

When working with clients on Cloud Migrations, the first step is to understand their environment. To do this, we start with a holistic view, formulating a detailed plan that serves as a roadmap. Using this roadmap, we work with the client to transfer and configure data (Database(s), Imagery, Flat Files etc.), working/project files (ArcMap/Pro documents, scripts, proprietary information), web applications and any third party integrations. After all configurations are complete, we validate the Cloud Environment through a client testing and QA/QC Phase to work out any and all issues. We then hand the keys over and GO LIVE!

We currently maintain infrastructure per environment (dev, QA, prod). How difficult is it to move and maintain all of that into the cloud?

Deploying and managing a 3-tier environment in the cloud is standard practice for many of the organizations we serve. Migration, when planned correctly can be a smooth and painless experience.

What are some of the requirements for cloud migration changes – CPU, balance charge, memory on demand, etc?

This really depends on the Esri software that is in use. You can find the specifications on Esri’s website. Here is a link to get you started: ArcGIS Server 10.8 system requirements—ArcGIS Enterprise system requirements | Documentation

What are some of the cons for GIS cloud migration?

There will always be challenges to overcome when encountering something different or unknown. If some of your data or technology is proprietary, you may not legally be able to deploy to the cloud. You may need to modify and/or map your application design and architecture to follow the cloud architecture. You could experience downtime due to technical outages (loss of power, maintenance, etc), but this would also be true on-premise

What does relocating a GIS environment to AWS look like? What about moving to Azure?

Migrating your GIS to AWS, Azure or any cloud solutions provider is accomplished in phases. Here is a brief overview of the methodology we use at ROK. Keep in mind that there are several steps within each phase, but this will give you an overview of what needs to take place.

  • Phase I: Spin up and configure the cloud environment you will use to support your software. Apply security, backup and retention policies.
  • Phase II: Install and configure your Esri Software. Deploy Virtual Desktop Instances.
  • Phase III: Migrate your GIS … this is a great opportunity to “clean the closets” and ensure you are only migrating what you need. We generally start migration planning in Phase I.
  • Phase IV: Cut Over to your new Cloud GIS environment. The entire process timeline varies depending on the complexity of your environment. As a very general rule you should budget 8-10 weeks.