ArcGIS Enterprise Registered Database Changed - Update Source Without Republishing All Layers?

Question

I have around 50 feature and map layers published in ArcGIS Enterprise (the same would apply for ArcGIS Online) that reference registered PostGIS database. The database will be migrated (same names, same structure, just the host will change). My hope is to avoid republishing every single layer one by one using Overwrite Web Layer or comparable sharing tool in ArcGIS Pro.

I researched everything possible and tried it out - available ArcGIS tools like "Manage Registered Data Stores" and updating the host in there. That does not update it in the published web service (that one still points to the old data store).

I played around with ArcGIS Assistant's "Update the URLs of Registered Apps and Services" function but that one also keeps the web service pointing to the old data store.

Is there a way to update my new database host without having to republish all of the ArcGIS Enterprise layers? Maybe programatically.

Answer 1

Host upgrades are an opportunity for prior planning to shine (or fail).

Keep in mind that networked computers communicate by IP address, not hostname. Most modern hostname-IP mapping is managed centrally from a domain name server (DNS host). The principal way to avoid having to republish all services with a new hostname is to reuse the old hostname on the new server. Thanks to DNS, the actual server name need not be the same, just that the symbolic name points to IP address of the actual server.

In a perfect world, you would have established the DNS mapping for all the major Enterprise components (the web server, the Portal server, the ArcGIS Server host(s), the Data Store host(s), the database host(s), plus any load-balancers), so that the symbolic names mapped to the IPs of the servers doing the work. In this way, adding separate server for a component that was initially configured to be shared (e.g., running the data store on a singleton ArcGIS Server node), would just be an issue of installing software, copying content, and redirecting the DNS name to the new IP. Similarly, adding a mirror or failover host would be a low difficulty task.

In the real world, architectures evolve, so it can sometimes be a bit messy, but the general concept can be retained -- Establish those domain names now, and start using the new names for new services and new portal items, while using outage windows to slowly migrate older named services to conform to the new naming model. Once you've been using the naming model a while, you can start retiring "old" names by removing them from DNS (experimentally, during regular maintenance, always checking that you haven't missed something important). You'd have to use this variant if the domainname changed, retaining the old domain server until migration was completed.