We have a currently deployed, public-facing production system that involves ArcGIS Server, Portal for ArcGIS with a webmap, and a webapp created by WAB-Dev, exported (downloaded), and deployed on our web server. We seek to migrate our operations to a new (beefier) production server, and would like to minimize downtime (and hassles). I was wondering if anybody had some thoughts or tips on possible pitfalls, gotchas, or strategies.
The only real difference in the servers is that one is running Windows Server 2008 with Tomcat 7.x, and the new one is Windows Server 2012 with Tomcat 8.5.x. Everything else should be the same: ArcGIS Server 10.5.1, Portal for ArcGIS 10.5.1, public map services published by ArcGIS Server backed by a file geodatabase (no Data Store or Enterprise geodatabase here). No federation-- everything on a single server (well, two servers-- the old one and the new one).
I read What is the proper workflow for moving Apps from Dev -> Staging -> Production? , but my situation is a bit less complex in that there's only two servers total, but different in that I want the new server to effectively replace (and take on the identity of) the old server. One thing that concerned me was, "make sure that you fix the map index in the map document level so that they do not change during the migration. Once you fix the indexes it will be permanent unless the indexes are changed." I don't really know what this is saying, but I've had problems with map indices when, for example, deleting a layer from a map service with a hierarchy of layers.
Anyway, I'm currently thinking of something like the following:
1. Set up the geodatabase and published ArcGIS services with the same folder structure, service names, etc.
2. Copy the webmap from the old portal to the new portal with the ArcGIS Online Assistant.
3. Copy the webapp from the old server, but change the AppID in config.json if a new AppID had to be generated to get it registered with the new server's Portal.
4. Make the server public-facing with a public DNS of, say, foo2.com where the old/current server is on foo.com.
5. Test that everything works when accessing foo2's webapp. This is basically a mirror site at this point.
[Here's where things start getting dicier...]
6. CHANGE foo2.com's webapp to point to foo.com's webmap and portal. Make sure it still works. In theory, the content is the same so it should still work.
7. Change public DNS so that foo.com now points to the new (foo2) IP address-- effectively making it the new foo.com.
[Here's where it gets even dicier.]
8. Quickly change the new server's portal to think of itself as foo.com, not foo2.com. Not even sure what's involved here.
9. Wait for DNS changes to percolate throughout the world, and now everything's in terms of foo.com on the new server.
In theory, I could skip Step 6, but in Step 8, also update the webapp to go from foo2.com to foo.com.
Yikes. Kudos to you if you got through this wall of text. Does any kind soul have any thoughts, tips, or revised strategies to consider? Thank you so much in advance.
