-
Notifications
You must be signed in to change notification settings - Fork 60
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
option to migrate despite errors #26
Comments
Hello,
Thanks for your suggestion to allow a migration with known errors.
At this time, the Migration Assistant is intended to do a “lift and shift” of sites that can run unmodified under Azure App Service. In the case where a site has known incompatibilities with the service, it should provide sufficient information so that the site administrator can address the issues before migration.
We’ve discussed the possibility of migrating known incompatible sites among the team a number of times, but feel that it is outside of the current scope. That said, we do revisit this topic periodically, and your feedback is important to help us weigh the decision against other work that we are doing to the Migration Assistant.
Thanks again,
-Wade
From: Anders Spælling <notifications@github.com>
Sent: Friday, January 17, 2020 12:22 AM
To: Azure/App-Service-Migration-Assistant <App-Service-Migration-Assistant@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Subject: [Azure/App-Service-Migration-Assistant] option to migrate despite errors (#26)
Something like the authentication type being WindowsAuthentication should not block the migration. For production it is not an option to disable this without a service window. Using something else like AAD auth in the web app would also require some code changes which one possibly will want to do on the migrated app.
Would be great if it is an option to "continue at own risk"
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAzure%2FApp-Service-Migration-Assistant%2Fissues%2F26%3Femail_source%3Dnotifications%26email_token%3DAJOMS7L7KFIDDITEX2Q4VQTQ6FTCNA5CNFSM4KIEQN7KYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IG3XT3A&data=02%7C01%7Cwadeh%40microsoft.com%7Ca2ab018917274ae14fdb08d79b2652b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637148461209160156&sdata=jtznXQ3rq7EBaKq67ztKXjbWBQUzicHeWRBxef4tTOM%3D&reserved=0>, or unsubscribe<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAJOMS7KOANZJDY3EXCGD66LQ6FTCNANCNFSM4KIEQN7A&data=02%7C01%7Cwadeh%40microsoft.com%7Ca2ab018917274ae14fdb08d79b2652b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637148461209160156&sdata=ve4ptNgCVkxoJkb5tbZvAhMwO%2FxWMt6EayyMAH33zQk%3D&reserved=0>.
|
That just severely limits the number of sites that is possible to migrate. My experience thus far is that lots and lots of sites use WindowsAuthentication, and in many cases simply to limit who can access the site, not necessarily using the token to identify the user. What I have done to use the migration tool is to export sites and import on a different VM with IIS installed. I am then free to change settings for a site to make it compatible. But in many cases it would be just ok to migrate an incombatible site and make a minor change once running in Azure. I hope you will reconsider you stance, perhaps make it a switch when you run the migration tool, so that it is a very intentional use to ignore errors and migrate anyways. |
The ability to package (and migrate) a site even with a failed configuration check is now possible using the PowerShell scripts option (use "-MigrateSitesWithIssues" flag on Get-SitePackage.ps1 script) - the scripts are a lightweight option that involves simply dropping a directory of scripts on the machine (or at least a machine-accessible location) in order to try it out. Main info page: https://github.com/Azure/App-Service-Migration-Assistant/wiki/PowerShell-Scripts |
Something like the authentication type being WindowsAuthentication should not block the migration. For production it is not an option to disable this without a service window. Using something else like AAD auth in the web app would also require some code changes which one possibly will want to do on the migrated app.
Would be great if it is an option to "continue at own risk"
The text was updated successfully, but these errors were encountered: