This site uses different types of cookies, including analytics and functional cookies (its own and from other sites). To change your cookie settings or find out more, click here. If you continue browsing our website, you accept these cookies.
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.
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.