Community Spring Cleaning week is here! Join your fellow Maveryx in digging through your old posts and marking comments on them as solved. Learn more here!

Alteryx Server Discussions

Find answers, ask questions, and share expertise about Alteryx Server.

Migrate server from on-premise to Azure details

ianjonna
6 - Meteoroid

Good afternoon friends

 

We have been asked to scope migrating Server/Gallery from on-premise server to Azure. 

 

Previously we have carried out server installs and upgrades for on-premise installations and a fresh installation in Azure, but never migrated from on-premise over to Azure. 

 

Please can someone point me towards some help pages so I can do some self learning. Additionally, could anyone share any carefully written notes or discussion items.

 

I'd be super grateful for any help 🙏 

 

Regards, ianjonna

2 REPLIES 2
brianscott
11 - Bolide

Following this thread so I can see how others have handled migrations in general; we are undergoing one and it is a total cluster.  

 

Our use case may be a little extreme considering somehow the database was corrupted and we had to start from bare bones, but even with that, I'd love to know how others have handled migrating database connections, macros, workflows that reference local file paths that change at migration time, schedules, the works.  

 

My first thought would be to estimate a time that it will take you do to this and then multiply by 5.  

salbol1
8 - Asteroid

We are in the midst of a on-prem to Azure migration, and I can second that it's not pretty. So much of the issue is that corps have such divergent models for handling identity management (IDM) roles than MS boilerplate, they try to take and convert to "their" IDM model, which is invariably wrong and leads to many scoping problems right out of the door. We are 6 weeks into just trying to get the service up and running, with all of the necessary peripherals like AD, SSL cert bindings, app registrations, port openings, IP white-listings, etc. that just get inherently more difficult because of the disparity between MS and internal documentation. So much of the Azure support just assumes admin and role functionality that is hard to track down in real world IT schemas - and the left hand not knowing right hand functions that uncovers.

Even knowing what these structures/procedures are in the existing on-prem get "clouded" when going to Azure, and I think trying to roll to that environment as quick as possible doesn't allow for many holes in the existing prem process to be rectified/updated/improved - so much of it seems to be GIGO to the new cloud process.

I certainly hope for many of you that's not your experience. While the strengths of being able to pretty much dynamically provision resources on the fly is awesome, and you can shut down services when not in use is cool for cost controls - getting to the point where those types of benefits can be realized is a daunting task that < deployment cycles haven't caught up to yet.