"Lift and Shift" AWS Migration Strategy Question

[RyanUthoff]

I am currently looking at migration strategies for migrating our on-premise ArcGIS Enterprise deployment to AWS. I know there are a couple migration strategies we could use, but the one I am looking at is the "lift and shift" strategy. This is where we just copy our VMs from on-premise and put them in the AWS environment.

My question is if this is a recommended or viable migration strategy we should use? Or would we be better off using other migration strategies, such as using webgisdr to do a backup and restore of our servers? We have a 4 machine deployment, along with the config store also stored on a server, all of which will be migrated into AWS. Since it is a "lift and shift", all hostnames will be staying the same. The only thing that will probably change are the IP addresses. But we used hostnames when configuring ArcGIS Enterprise, so I think we will be okay with that.

The "lift and shift" strategy is the most simplest and straightforward for us, but I haven't seen much documentation on if this is a viable strategy for migrating ArcGIS Enterprise into AWS. Or if this is just a bad idea with disaster written all over it. Are there any reasons why we shouldn't use this migration strategy? Or anything to look out for if we choose this migration strategy?

[DevinBartley2]

We successfully completed a Lift and Shift migration from our on-prem servers into the Azure cloud last month. The project went quite well, thanks in a large part to doing our research beforehand and having a good detailed understanding of our system. If anyone is considering doing this I'd say that you must be able to do the migration during a full system outage (if you have to keep things live then Lift and Shift is probably a bad choice),  have a good understanding of your system and its dependencies, have a test environment to test the deployment, a solid working relationship between IT and GIS, a good understanding of Cloud offerings and concepts, and the ability to troubleshoot the inevitable problems that may occur. 

A few things to note:
-The only major problem we ran into was our hosted feature layers broke when we first tested the migration. The solution was running the allowconnection.bat tool which modifies pg_hba.conf to allow connections between the data store machine and the arcgis server machine. More info: ArcGIS Data Store utility reference—Portal for ArcGIS | Documentation for ArcGIS Enterprise

-ESRI is correct that if you try to connect to your Enterprise Geodatabase in the cloud from a local desktop install of ArcGIS Pro it simply will be slow to work. I was skeptical but yes, it really does not work. You must deploy a GPU enabled Azure virtual desktop in the same cloud region as the database to run ArcGIS Pro. For me personally the smallest Nv_V4 machine with 1/8 GPU worked fine. However, the low amount of RAM on that machine didn't work when I also had a bunch of large PDF files open alongside ArcGIS Pro. In the end I bumped up to the 1/4 GPU Standard_NV8as_v4 and I am happy with the performance. I shut this machine off while not using it to save costs.  More info on these machines here: NVv4-series - Azure Virtual Machines | Microsoft Learn

- Be aware that file storage speed is an important consideration, especially when working in ArcGIS Pro and I found especially so when working with file geodatabases. We went with Azure Files, and it works okay, but NetApp Files is recommended for optimal performance. 

Overall the only reason we went with Lift and Shift is because that is how our IT scoped out migrating all of our organizations systems and because we had a very short timeline and limited budget to complete the project. We will soon be doing a complete system build from scratch with the Enterprise Cloud Builder and migrating/rebuilding our content there. This will allow for easier updates or expansions to the system in the future. 

I used the System Log Parser tool to collect benchmark metrics on the on-prem system performance, and then ran it again once we migrated so that we could compare the systems. Overall our Enterprise deployment in Azure is actually slightly faster than on-prem in terms of how the ArcGIS Portal services perform. This is because we used slightly better machines in Azure than we had on-prem. Also, we have a 70ms latency to the Azure data center and I don't notice any issues there in terms of how things perform. 

[DevinBartley2]

Just an update to this - one issue we have ran into is file geodatabases are incredibly slow when stored in Azure Files. ArcGIS Pro projects stored in Azure Files that connect to our Enterprise geodatabase seem to work fine, but if you have to do geoprocessing or field calculations on a file geodatabase in Azure Files it is not ideal. To be fair, we were warned about this. I am currently looking into Azure NetApp files or another solution.