Server 10.9.1, changing the service runtime from Arcmap to Pro Question

[Royce_Simpson]

I've started to go through my 10.9.1 services and change them via Manager over to the Pro runtime.  One thing that I thought would happen would be for the "./directories/arcgissystem/arcgisinput/foldername/service.MapServer/extracted" v101 folder and its contents with the .msd and .mxd files to be migrated to a p20 folder and .mapx file.  This doesn't seem to be happening.  

I was hoping to be able to use the resulting .mapx files to replace my old mxd project files in the likely cases that I'll need to republish various map services with updated symbology, layers, etc...  As is, it seems that even though I've changed the runtime for these services to the Pro runtime, I don't actually have any working map documents in Pro.  Am I forced to copy the mxd that is still in that "extracted/v101" folder and manually go through the full Pro migration with those, one at a time?  If that's true, would the manual migration process from mxd to Pro produce the same map that Server is now using with its Pro runtime (after changing the runtime from ArcMap to Pro from within Manager for each service)?  Also, what would happen if someone tried to republish to a service with their mxd after I've changed the runtime to Pro?

Thanks.

[MelissaNorthey]

Hi Royce,

I'm a bit late to this and don't offer exact answers but I am also in your shoes with upgrading our services to use Pro runtime since upgrading our server to 10.9.1.  I found the same thing - no updated working map file.  Here's a list of what I've found/run into:

• I did get a handy script put together to convert all MXDs in a directory to APRXs.  I'm willing to share with anyone interested.
• I have been upgrading services as changes have been requested by overwriting them with an APRX.  
• I've been getting "SEVERE" errors in my logs and Esri Support has suggested that my overwriting/upgrade approach may cause that and they've also linked me to a few bugs.  These bugs seem to only happen on my services that use the Shared Instance type.  My solution for now is to make them all dedicated but this is not desired as Shared instance types are supposed to be a perk of the Pro Runtime services.

Lastly, as you probably already figured out, once you go Pro you can't go back.  There's no way to overwrite a Pro Runtime service with a MXD - you will get an error.  The only way to do this is to delete the Pro service and recreate it with a MXD naming it the same.  Good luck to you.

[Kim_Graham]

Hi Melissa,

We are just starting to map out our plan to do this in the next month or so and have been discussing the best way to republish or switch to the Pro runtime.  I would love to look over your script if you're still willing to share.

Thanks!

Kim

[MelissaNorthey]

Hi Kim.  I attached the script below in response to Royce's request too.  

[Kim_Graham]

Thank you!  I appreciate it.

[Royce_Simpson]

Hi Melissa.  Thanks for the thoughtful response.  I've put off upgrading my services to Pro and need to get my head back into that game.  Something that has occurred on a couple of occasions is that the resulting "Pro Runtime" services present the data differently than the Arcmap-based ones.  For example, we have a web app that uses one of our map services to do a query against one of the layers in the service.  Via the Arcmap-based services, the results come back from the query one way and the results come back from the Pro-based service a different way.  That breaks our web app and will require the app to get some code changes.  The main aggravation with this is that we don't know what breaks until we make the move to the Pro runtime and see what comes of it.  That's a crumby way to do things but in most cases, is our only recourse. So now, I'm on my heels a bit and keep putting off this Enterprise 10.9.1 to 11.x upgrade because I know lots of gremlins are going to come out of the woodwork. 

That doesn't even touch on this "how to properly upgrade the services" question.  I thought I could just go into Server Manager and do a clean sweep and upgrade everything and I'd have nice Pro-based maps in the server "extracted" folders.  Not so.  So, upgrading the services via Server Manager brings no real value.  I need to make sure every service that's in production has a corresponding Pro map for the eventual need to "overwrite and republish" services.  The only way to do that is to, one at a time, or perhaps with a script like yours, migrate the source maps from MXDs to Pro maps and then republish.  Again, that's a daunting set of tasks and puts me on my heels. 

So, I've got a nested set of hurdles to jump before I can call this complete.  I guess the journey of 10,000 steps starts with step 1.  No other way around it. 

Cheers.  If you'd be willing to share your script, that would be much appreciated.   What is your experience with automating that migration and having the resulting Pro maps replicate the MXDs (symbology, labeling, def queries, scale-dependent visibility, etc...)?

[MelissaNorthey]

Hi Royce, my apologies for not replying sooner - I missed the email for this one.  I've attached the script below.  The MXD settings for symbology, etc. stay through to the APRX file fine.  You will find that you need to change custom label expressions to use Arcade to get them to display properly in ArcGIS Online.  I'm thinking that this is what you are experiencing with your web app query too possibly.  Good luck to you.