Change organization URL after installing Enterprise 11.5

Question

Hello everyone,

I'm standing up an isolated environment for a client's ArcGIS Enterprise upgrade (10.9.1 → 11.5), built fresh on AWS rather than upgraded in place. The goal is to validate workflows before cutting over to production.

The new environment will run at https://gistest.company.com/portal so I can test publishing, Experience Builder apps, traditional versioning with two-way replication, and a set of Esri hardening and IIS security changes. Once testing is complete, I need to point the URL back to https://gis.company.com/portal.

The blocker: a host-file edit won't work here since these workflows need to hit the real internal ArcGIS Enterprise environment. I also can't update the license file on my.esri to reflect the test URL — if I delete the existing portal license and generate a new one for gistest.company.com, I then can't reach the portal to apply it, since the portal URL and license URL are out of sync.

I found Esri's doc on updating the organization URL (link below), but it's light on detail, and I'm not sure whether following it risks breaking federation with the rest of the site (Server, hosting, etc.):

Update the organization URL — Portal for ArcGIS | ArcGIS Enterprise 11.5 docs
https://enterprise.arcgis.com/en/portal/11.5/administer/windows/update-the-organization-url.htm

Has anyone gone through this URL swap (test → prod naming) on 11.5 without breaking federation, or found a cleaner way to license a temporary environment for this kind of side-by-side testing?

Thanks,
Lavanya

ArchitSrivastava · Answer

Hello @LavanyaVasudevanNES ,

Thanks for the additional details. That makes the setup much clearer.

Since the current 10.9.1 production environment will not be touched, and the new 11.5 environment is completely separate, this sounds cleaner than trying to modify the existing production deployment directly.

Also, since the Portal items, maps, layers, apps, and tools from gistest do not need to be preserved after the URL change, that removes some of the risk around item URL updates and content dependencies.

In that case, your idea of using the test environment to validate the URL change workflow makes sense to me. The intermediate step:

gistest -> gistest2 -> gis

Could be useful as a rehearsal before the final go-live change. It would let you confirm the URL update sequence, federation behavior, IIS / hardening behavior, and license timing before moving to the final gis.domain.com URL.

For the licensing part, I agree with your thinking. Provisioning a new license file for the final https://gis.domain.com/portal  URL sounds cleaner than trying to modify the temporary gistest license, especially since the new 11.5 environment will eventually become the production environment.

The main thing I would still be careful about is treating the go-live step as a full Enterprise URL change, not just a Portal rename. Even if the content does not need to be preserved, I would still validate federation, Server URLs, WebContextURL, DNS/IIS routing, Portal licensing, ArcGIS Pro connections, and the geodata service after the URL change.

Some IT / cutover items I would also keep in mind separately are:

* DNS cutover timing from gistest.domain.com to gis.domain.com
* Lowering DNS TTL before the cutover window, if your IT team allows it
* Confirming the final DNS record points to the correct load balancer, reverse proxy, or IIS/Web Adaptor endpoint
* IIS bindings for the final hostname
* Web Adaptor URLs and routing after the final hostname is active
* Firewall/security group rules for the new 11.5 machines
* Load balancer health checks, if one is used
* Certificate coverage for the final gis.domain.com hostname
* Confirming old gistest references are no longer used after go-live
* Checking whether any internal scripts, scheduled tasks, integrations, or asset management workflows have hardcoded URLs
* Confirming monitoring/logging is watching the new 11.5 environment after cutover
* Having a rollback or fallback plan documented, even if the old 10.9.1 environment is not being modified

For your environment, the most important validation after the URL change would probably be:

* Portal and Server federation validation
* ArcGIS Pro connection and publishing
* Geodata service access
* Traditional versioned editing
* Two-way replica creation and synchronization
* Asset management system edits flowing back correctly
* IIS and Esri hardening rules after the final URL is in place
* Portal and Server logs after the change

So I do not know of a much quicker supported shortcut, but based on what you described, your plan sounds reasonable: Test everything under gistest, rehearse the URL update if needed, generate a fresh license for the final gis.domain.com URL, and then do the documented URL update process at go-live.

Hope it helps!

LavanyaVasudevanNES · Answer

Hello Archit,  Thankyou for the detailed response.  I really appreciate it.   The patch has been installed.  Here is a bit more detail on the implementation.  Current production is at 10.9.1.  Its url is https://gis.domain.com/portal.New production is configured at 11.5 with the https://gistest.domain.com/portal URL.  It will have the https://gis.domain.com/portal after GOLIVE.   I am installing a brand new 11.5 where I will need to test: - replication with traditional versioning since client does not want to convert over to Branch or unversioned.    - this will have to be a two way replication since the asset management systems also modifies the attributes in the database.  - client has on prem sde they make edits on         - current replication is being done on via a 10.9.1. on ArcMAP and I feel testing the process is important before going live.         - need to test the geodata service and troubleshoot any issues we run into.  We have also implemented some ESRI Hardening Rules along with some IIS hardening steps.  I feel like the test environment might help us figure out all the little nuances before we GO LIVE.  None of the data or the web maps are required to be carried over from gistest to gis. We are completely okay with the URL changing for the portal items, maps, layers, apps and tools.   No SAML is currently being used in the test environment so that clears that up.  We will implement it when we GO LIVE. Certificates are currently CA signed wildcard on IIS, portal admin and server admin endpoints, so that shouldn't be a problem.Pro will point to the correct URL.   I am unable to change the URL on the my esri licensing file from the current gistest to gis.  I should probably provision a brand new license for the URL I need and use that instead of trying to modify what I am currently using to test.   Honestly I wouldn't mind testing out the URL change workflow with an intermediate step:  gistest -> gistest2(confirm, validate) -> gis None of this above testing(including the license file URL changes) will touch the current production which is at 10.9.1.  I was hoping there was a cleaner/quicker way of accomplishingthis URL change.   Thanks lavanya

ArchitSrivastava · Answer

Hello @LavanyaVasudevanNES

I have not done this exact 10.9.1 to 11.5 side-by-side URL swap recently, but a few things stand out from the 11.5 documentation.

First, I would be very careful with the Update organization URL workflow at 11.5. The documentation currently has a caution that this workflow is impacted by a defect and requires a patch before proceeding:

Update the organization URL—Portal for ArcGIS | Documentation for ArcGIS Enterprise

So I would definitely confirm that patch is installed before testing this workflow.

The second thing is that this does not look like a simple Portal URL change only. From the documentation, the workflow updates URLs across the Enterprise organization, including:

* Portal URL / organization URL
* Portal Administrator Directory
* Portal items, maps, layers, apps, and tools
* each federated ArcGIS Server URL
* services, Server Manager, Server Administrator Directory, and Services Directory

So if you go from:

https://gistest.company.com/portal

to:

https://gis.company.com/portal

I would expect the federated Server URLs to need the same careful handling as well, not just Portal.

A few things I would check or plan for before doing the swap:

* Install the required 11.5 patch mentioned in the documentation
* Create a full WebGIS DR backup before making the change
* Make sure all federated servers validate correctly before starting
* Generate and save the URL reports before updating anything
* Update federated server URLs first, then update the Portal URL, following the documented order
* Confirm WebContextURL is set correctly for Portal and each federated Server before the change
* Update reverse proxy / load balancer / DNS / Web Adaptor routing as needed
* Confirm certificates include the final production hostname
* Check whether SAML/OIDC redirect URLs or metadata need updates
* Plan for ArcGIS Pro users to update their portal connection after the URL change
* Plan for a new Portal license file for the final organization URL after the change

For the licensing part, I would be cautious about deleting or regenerating anything tied to the current production environment in My Esri. Since this is a temporary side-by-side environment that will later take the production URL, I would probably confirm the safest licensing approach with Esri Licensing or Support before changing the production portal license allocation.

My understanding is that one possible path is to license the isolated test environment with the temporary URL, validate the workflows, then at cutover follow the organization URL update workflow and import the correct license file for the final URL. But because this involves the production organization URL and licensing, I would want Esri to confirm the exact sequence.

After the URL change, I would test more than just whether Portal opens. I would check:

* Portal sign-in
* Federation validation
* Hosted feature layer access
* Referenced services
* Publishing from ArcGIS Pro
* Experience Builder apps
* Web maps and dashboards
* Traditional versioning workflows
* Two-way replication workflows
* Item thumbnails and attachments
* Server Manager and Server Admin URLs
* Portal logs and Server logs
* ArcGIS Pro portal connection and licensing behavior

So I think the workflow is possible based on the documentation, but I would treat it as a full Enterprise URL migration, not just a Portal setting change. The 11.5 patch requirement, federated server URL order, WebContextURL, certificates, licensing, and app/service validation would be the main areas I would be careful with.