Select to view content in your preferred language

New deployment GIS Enterprise 12

1519
11
03-11-2026 10:26 AM
dwebeltch
Emerging Contributor

Have a customer that wants to upgrade to the newest GIS version but also wants to move the back-end to Azure. This customer has zero IT experience and only knows how to use the GIS system.

I'm a bit confused on how this is set up. I've read the documentation and watched some videos but things still aren't connecting.

There's a 1 server setup or a 6-7 (or however). Why use so many if 1 suffices?

There's something called Portal but also something called Online. We were assuming the Servers connected to the Online portal to work but some things read like this is set up as a web server. We don't want to manage a web server so is this something that connects to a SaaS front-end tenant?

The confusion in this is making it difficult to figure out what questions to ask to get this going so I'll stop here and see where this takes me.

thanks.

 

0 Kudos
11 Replies
RyanUthoff
MVP Regular Contributor

I think your best bet here is to hire a consultant that will understand your needs and build out a system that meets your expectations because there is a lot to unpack here and it's extremely important to set everything up correctly from the start, otherwise you're going to run into issues down the road that will cost the organization time and money.

To briefly explain, you have ArcGIS Online and ArcGIS Enterprise.

ArcGIS Online is a SaaS offering where all your data is stored on Esri's servers. You hosting any infrastructure or software is not a requirement.

ArcGIS Enterprise is where you host the infrastructure (whether on-prem or in the cloud) as well as the Esri software. Since your customer is wanting to upgrade and move to Azure, this tells me they are already using ArcGIS Enterprise. This means AGOL is irrelevant unless they want a hybrid option where you use a mix of Enterprise and AGOL.

If you don't want to manage any web servers, then you will need to use AGOL as AGOL takes care of all of that for you.

Alternatively, if you don't want to manage anything but need to stick with ArcGIS Enterprise, you can hire a third party to manage it all for you. Considering your organization doesn't have any IT experience, I think this will be your best bet. You absolutely need someone who knows what they are doing to build out and manage and maintain your IT and/or ArcGIS Enterprise environment. 

dwebeltch
Emerging Contributor

Oh sorry I didn't add. We are the consulting for IT. I can build whatever I just don't understand what I'm supposed to be building here.

I can build out the servers they need, but my real issue is not understanding how this all fits together. 

I was under the impression that we build out a server with the components installed. Then this server connects outbound to a SaaS web portal run by GIS that allows everything to talk/function and for users to interact and use the product. Is this not the case? 

If my thinking is right then why would we need an application gateway or anything like that when a public IP would suffice to connect the server to GIS Online. This would be an outbound only connection correct?

Thank you for the help.

 

 

0 Kudos
RyanUthoff
MVP Regular Contributor

Ohh, I see. Thanks for the additional information. 

ArcGIS Enterprise can be deployed in various ways. There is not an issue with all components being installed on the same machine, just as long as the machine has enough resources to be able to support everything.

For a base ArcGIS Enterprise deployment, you can install everything on one machine.


I was under the impression that we build out a server with the components installed. Then this server connects outbound to a SaaS web portal run by GIS that allows everything to talk/function and for users to interact and use the product. Is this not the case? 


I'll directly respond to your statement above and hopefully clear things up. For a base ArcGIS Enterprise deployment, there is no SaaS. You host everything on your servers. There is no ArcGIS Online. ArcGIS Enterprise includes three components: Portal, Server, and Data Store. Then you also need the ArcGIS web adaptors or some kind of third party load balancer.

Portal is how most end users typically interact with it. That's how they access their web maps, etc. The ArcGIS Server is essentially "connected" to Portal. So all the map services you publish to Server will appear in Portal for people to view and access. You would need an IP address for Portal in this scenario.

Now, I did see your follow-up comment about the hybrid deployment. Keep in mind that organizations can have multiple variations of a "hybrid" environment. From how you're describing it, what I am assuming is happening is that you have deployed ArcGIS Server on-prem, but then want to connect ArcGIS Server to ArcGIS Online, which is how people use the web maps. In this scenario, your end users publish services to the ArcGIS Server. Then, they take the service URL and add it to ArcGIS Online. That is certainly one variation of a hybrid deployment. You are technically correct that the end user's connections go through ArcGIS Online, however ArcGIS Online will still need to communicate with your on-prem ArcGIS Server to retrieve the data from the service.

0 Kudos
JoshuaBixby
MVP Esteemed Contributor

You may be consulting for/on IT, but it is clear you have very limited knowledge of GIS, so the earlier comment about hiring a consultant still applies.  ArcGIS Enterprise is a complex platform with many components.  Which components get deployed and how depends on the businesses requirements, but having requirements means little if it isn't accompanied with understanding the product itself.

0 Kudos
dwebeltch
Emerging Contributor

Another bit of information; the client calls this a 'Hybrid' deployment where connections go through GIS Online and not to the internal servers themselves. 

I hope that makes sense.

0 Kudos
LavanyaVasudevanNES
Regular Contributor

Just to help you get this started, check out: 

https://architecture.arcgis.com/en/

and 

https://enterprise.arcgis.com/en/

Hiring consultants to help with the ArcGIS Enterprise is possibly the best option given that the client already has a system and needs that upgraded/migrated.   Unfamiliarity with AGE can break the current production systems causing a bigger issue.  

 

0 Kudos
D_Atkins
Frequent Contributor

Comments so far seem to have missed the "Azure" in your opening post.  In this case (and Community, please correct me if I'm wrong), a request for Azure-cloud service can be as simple as replacing on-prem RDBMS (SQL, Oracle), but not always or necessarily any other ArcGIS Enterprise components (Server, Portal).  

Of course, you can go full cloud with Enterprise these days: Introduction to ArcGIS Enterprise on Microsoft Azure—ArcGIS Enterprise in the cloud | Documentation ...


Which reiterates others' question: what is hybrid?  

   * ArcGIS Online & ArcGIS Enterprise, both in the cloud: not uncommon but a bit redundant.  We use both for different redundancies and traffic distributions.  But then it's really two different systems -- 'two organizations' that can participate in a Collaboration model: see About distributed collaboration—Portal for ArcGIS | Documentation for ArcGIS Enterprise and Collaborate between ArcGIS Enterprise, ArcGIS Online and ArcGIS Field Maps 

 Despite the 'collaborations', administration of user accounts will likely vary between the two systems.

   * The other common Hybrid model: Cloud data storage/redundancy with an on-prem Enterprise deployment.  In this instance, you're just replacing references to SQL or Oracle with an Azure backend.  In this case, administration is more streamlined to 'one instance' of ArcGIS.

In either case, Arc does not include the RDBMS -- it's an abstracted layer on top.

---------------------

One thing you haven't really clarified is what your starting point is?  What version Geodatabases, and what is the backend (Oracle, SQL).  If this an established organization with a decade or more data, and is still reliant on ArcMap, WebAppBuilder, Geometric Networks, or any other of ESRI's deprecated tools, then simply deploying a new environment is barely scratching the surface of an 'upgrade'.  Of course, if it's a younger org primarily working out of File Geodatabases, then it's a bit more streamlined.

0 Kudos
RyanUthoff
MVP Regular Contributor

I didn't include the DB component since that was not asked about, but if we really want to go down the Azure rabbit hole, we need to consider EVERY component that touches ArcGIS Enterprise.

So as you mentioned, the DB's are an important component of that and will need to go up to Azure along with ArcGIS Enterprise. And of course there are various implementations of that, whether that's rolling your own install of a DBMS in Azure or using Azure's cloud-based DBMS. Depending on the implementation the organizations uses, it could possibly involve a lot of work in pointing the existing servers to the new DBs.

Not only that, but we need to think about how the end user interacts with the data in the DB. Any users that use ArcGIS Pro that make database connections where the DB is hosted in Azure will need to have a workstation in Azure as well. That's not a hard requirement.....but trust me when I say that if you don't have that, your productivity will be killed by terrible latency. 

I guess what I'm trying to say is that moving to the cloud is an all or nothing situation. You can't necessarily move some components to the cloud, while leaving other components on-prem. Sure, it might technically work, but the performance is going to be terrible if it's not all or nothing.

This is exactly why I said in my previous post that their best bet is to hire a GIS consultant that will come up with a comprehensive solution to not only migrate to Azure, but to ensure everything is setup correctly from the start. 

0 Kudos
D_Atkins
Frequent Contributor

I disagree that "moving to the cloud is an all or nothing situation" but acknowledge that it requires careful consideration of the data volume, the desired velocity (no pun intended, ESRI), and so forth.  

My post was more intended to highlight exactly what you say, "if we really want to go down the Azure rabbit hole, we need to consider EVERY component that touches ArcGIS Enterprise."   It doesn't sound like @dwebeltch has a strong grasp on how many different tools and components are included with Arc.

We can even keep it more directly on topic: which combination of GIS Servers do you need? ArcGIS Enterprise servers—ArcGIS Enterprise | Documentation for ArcGIS Enterprise


@RyanUthoff wrote:


This is exactly why I said in my previous post that their best bet is to hire a GIS consultant that will come up with a comprehensive solution to not only migrate to Azure, but to ensure everything is setup correctly from the start. 



@dwebeltch  wrote:

We are the consulting for IT.


0 Kudos