I know many users are keen to upgrade and start using ArcGIS for Server 10.1 but there needs to be a plan in place before one migrates. As many of you are aware, AGS 10.1 has been redesigned and comes packed many new features that make our lives easier. These are all wonderful but users need to understand these changes. 

New installations are easy and simple where as migrations are complex and time consuming.

I migrated our production basemaps last night. These are on http://services.arcgisonline.co.nz. This was an AGS running 10.04 and had ~ 4 services. One might think that this would be reasonably straight forward with a simple uninstall of AGS 10.04 and install of AGS 10.1. 

~ 4.5 hours later I was still going. I was also conscious of downtime as this is a production server. No the services were not down for ~ 4.5 because I did this in parallel. They were down for ~ 10 minutes. 

Why did it take so long? Well it had to do with existing data, caches and services and reconfiguring this for AGS 10.1

So I strongly suggest that existing clients with larger or complex installations of AGS 10.1 spend time planning their migrations. It’s not as simple as going from AGS 9.3.1 to AGS 10.

Perhaps a health check from a BP or our Professional Services Team might be required to understand what the impact will be and due to a typical migration being time consuming I would recommend this be done in parallel. 

Here are a few technical aspects to take into consideration when thinking of migrating to AGS 10.1:

1. Make sure you thoroughly understand AGS 10.1. Conceptually it’s the same but technically very different.
2. Understand the environment you are working in. AGS 10.1 ties itself closely to the network and if DNS’s and domain names are not configured properly the site creation will fail.
3. Understand how the web adaptor works. This will be needed for those clients that are migrating so that backwards compatibility is maintained.
4. All existing services will need to be republished. MXD’s and MSD’s are no longer supported. Users will have to go back to the source data, open this up in AG Desktop 10.1, run through the sharing wizard and analyse the document. Correct any errors. The analyser is a lot more sensitivity at this latest release.
5. All existing data sources will need to be registered with AGS 10.1. You need to do this as part of the publishing process. 
6. If you are publishing existing cached map services, you need to make sure that their conf.xml files can be read by AGS 10.1. This might require manipulating the conf.xml to suit so understanding how the new caching system works in AGS 10.1 is equally as important.
7. There are many changes to the REST interface so familiarise yourself with where things are. Once existing services are published they are backwards compatible.
8. Determine whether users require HTTPS. This requires a whole separate set of configuration. It’s also harder if you are working with the web adaptor so make sure this is planned. Existing CA certifications cannot be easily imported into AGS 10.1 but you can used the self-signed certificates easily enough. You need to work out if these scenarios work for your environment.
9. There is a breaking change on the REST interface with the GeometryServer being moved to the utilities directory as opposed to the root so evaluate what impact this will have on other applications.
10. Plan the relevant permissions. The authentication models are AGS 10.1 have changed. If you are using tokens, make sure these are configured appropriately.  

Are you working to put together a migration plan for the transition to ArcGIS for Server 10.1? Because there are significant changes in the software architecture at ArcGIS for Server 10.1 a number of hints and tips have been put together to help you through the process.

Good to Know’s

• At ArcGIS Server 10.1, service configuration files from previous versions will no longer work. (At previous releases, service configuration files would remain valid.) Version 10.1 uses a different mechanism for map services called the Service Definition (SD), which is not a text configuration file as it was in previous versions. Previously created map caches will remain valid.
• ArcGIS Server 10.1 no longer uses SOM and SOC.  At 10.0, you had to manage accounts for each, but at 10.1, you’ll only have to manage one account.
• The concept of a distributed installation with multiple SOC machines attached to one or more SOM boxes is also going away. Each GIS server is its own installation. GIS server machines and services may be clustered together using tools available in ArcGIS Server Manager to offer better computing power, but each ArcGIS Server machine is effectively autonomous.
• There is no longer a differentiation between the Java and .Net versions of ArcGIS Server.  Now it’s just ArcGIS Server. The product installs with its own application server; this server should be dedicated to ArcGIS Server and nothing else. Esri has created applications, called “Web Adapters,” that link your current server of choice (IIS or a J2EE application server) to the GIS server instance. These applications are small broker components that basically forward requests from your web server to the internal server used with ArcGIS.
• When you create an administrative connection to ArcGIS Server 10.1, you’ll have the option to package and copy data in the Service Definition and push the whole package up to a GIS server. This means that an SD is portable – a user in one location can create a service definition and ship it to the GIS server owner without having to worry about an account having access to data in the remote location.