Migrating ArcGIS Portal

[RogerDunnGIS]

I'll start with an introduction.  I've been a GIS Administrator for more than 20 years.  I've been a part of each upgrade and migration of each server GIS product from ArcIMS to ArcGIS Server 10.9; I've migrated geodatabases from multiple-to-single instances, sde services to direct connects, and from one machine to another.  However, I'm new to ArcGIS Portal and Data Store, which I inherited in this new job.  We are on the Small Government Enterprise Agreement.

In 2023, I will stand up ArcGIS Enterprise 11 on a new server machine.  Our current Enterprise is at version 10.8.  I have some goals with the new server.  I want to migrate user accounts to connect to Active Directory.  Content has to be republished or moved (not sure).  I want to reorganize content and shift ownership of some web items to other users.  I want to make some items more private and some items more public.  I have to stand up the server side-by-side with the production server, so that URLs will be temporary at first, and then shifted to production URLs on some future go-date.  We have Server services, web items, maps, apps, duplicates, and disconnected items.

All I need from you, the community, are useful helps, tips, URLs, blog posts, and documentation to help me in my goals.  YouTube videos aren't as useful to me, but I'll try to utilize anything I get.

[BillFox]

you get to start fresh - yeah! go all-in for an HA setup

[RogerDunnGIS]

Pardon me, but what is an "HA setup"?

[BillFox]

Example: https://community.esri.com/t5/telecommunications-videos/telecom-gis-in-five-minutes-video-series-epi...

An HA setup can really help minimize some user interruptions for routine things like Microsoft, Esri updates, security patches, vmware tools updates, etc. Hard everything down maintenance windows are hard to get and hard to squeeze everything into a typical hour or two.

[RogerDunnGIS]

Thank you for linking in the video.  I'm watching it now.  For those looking at this thread post-mortem, "HA setup" stands for "High Availability Setup".

Still, there must be a way to stand up this side-by-side server under a different URL and a * security certificate; then have a go-date where we take down the old and replace it with the new.  I'm almost positive that everything to do with Server and Portal and URLs are all stored in strings across multiple files, the registry, and in databases.  One can't simply find-and-replace old-URL with new-URL on the go-date?  I sort of thought that "staging" was the name for this process.

[TonyContreras_Frisco_TX]

You are correct that there should be a way to do this and there is, but it is not supported so if you run into trouble you are on your own trying to fix it and you may run into unexpected issue later on. Our current environment was set up at the same time as our old production servers, with different web adaptor URLs (pre-production and current production).

When we were ready to cut over, I used the portal admin page and sharing page in the new portal to update the federated and hosting site's web adaptor URLs (don't change the admin URL, set that up with a stable internal web adaptor when you initially set up the servers and then do not change them). Then I used the arcgis python API to get all the services and changed their web adaptor URL paths and URL paths for each webapp in the portal. The other big task is updating all the webmaps so that the URLs for the services go back to using the old web adaptor (I used Notepad++ find and replace in all files).

There are a lot of other little things to do, all of which require having deep understanding of how the portal works and being able to troubleshoot the various anomalies that no doubt will pop up. I don't recommend using this method because there is so much that can go wrong and you don't want to do this every time there is a clean install on new servers, which I recommend over in-place upgrades that can have strange behaviors.

We are going through this same process now, trying to decide how to migrate to all new servers. The biggest issue for us is losing the itemIDs of all the Portal content, which can be avoided for out of the box webapps and webmaps by creating them in ArcGIS Online (if the security policy allows that). Then, depending on the number of services, the services can be republished during a maintenance period to the new services that are set up with the old Server Web Adaptor URL.

[ReeseFacendini]

If you want to reorganize content, and possibly do some cleanup along the way, republishing is the best option for that. There are also tools to help migrate web maps, web apps, etc., primarily being the ArcGIS Python API (need ArcGIS Pro). ArcGIS Assistant (formally known as ArcGIS Online Assistant) is also a good option, for something with a GUI. This blog post talks about moving items across tiered environments, and while that's not exactly the situation described above, it's directly related to what is being attempted.

One item to keep in mind is that changing URLs of an Enterprise deployment after configuration is not supported. When you pick a URL, it needs to be the URL that will be used after the migration effort is complete. DNS aliases are supported to have something easier to type into the browser, but those too cannot be changed after the fact.

[RogerDunnGIS]

These are all great ideas and leads.  Thank you so much.  If anyone else has ideas on how to stand up a replacement server while production is still active, I'd appreciate any more URL's, blogs, threads, documentation, or any other help you have found helpful.

[JoelHearne]

Thank you crafting this question so succinctly. I also prefer side-by-side upgrades whenever feasible but, I am not seeing how that is possible if changing the URL/FQDN after-the-fact is not supported.  Perhaps a staging server could be built and then the Web Adapter simply reconfigured to point at the new server.  Also, wouldn't a side-by-side approach require a second ArcGIS Enterprise license and a separate AGOL organizational account?

Has anyone tried creating a backup using webgisdr and then restoring it to a fresh installation?

[Scott_Tansley]

The typical way to do this is to start with a new subdomain, as people have said above.  Many of my clients had ArcGIS Enterprise on https://gis.domain.com/....  as a part of starting again they would move to something like https://maps.domain.com or https://spatial.domain.com Then they use the tools that have been described above to move content, 'chunk by chunk' so that the permissions and ownership can be changed as you describe.  

The idea of webgisdr is great, but you can move from one enterprise to another, only if both use the same URLs and only if they're both at the same software version.

The primary issue is that when you create an item in portal, then the JSON is stored on disk within the portal.  Each JSON file has the URLs to the services, web maps or whatever hardcoded into that JSON.  So if you try and copy content directly from gis.domain.com to maps.domain.com, then it will still point back to gis.domain.com.  Obviously when you turn that off then those items will break. 

This is fundamentally why we cannot call an environment gistemp.domain.com, with the hope of renaming it to gis.domain.com, once again the internal hardcoded URLs would still be gistemp, and there is no supported methodology for changing them.  

Once you configure an Enterprise with a subdomain, and then create your first item of content, then you are locked into that subdomain.  You're looking at a migration, or the tools for moving between tiers (discussed above) to make things work.