I haven't run into that specific error, as far as I can remember.  But, I rarely install/upgrade IN Azure web apps, unless the available resources are able to be scaled up well beyond what it needs (during the install/upgrade process).  In those cases, I'll pull the site down, perform the work, then migrate it back.  It seems to be faster, even, using that workflow.  

However, it's worth your time to look in the folder below to see what the log files say about the installation error(s).  

<code>~/Portals/_default/Logs/</code>

Thank you so much for the reply!

I ended up grabbing version 9.4.4 from the github and installing that version. The installation proceeded without issue. I have a 9.4.4 site on another server I intend to migrate that is currently running 9.4.4 - I wanted to prove out the newer version in Azure before I invest in upgrading that site. I've opted instead to keep the source and destination versions at 9.4.4 since that's what I was able to get up and running at the destination.

Are there any special considerations I need to take into account for a migration to Azure? I have packaged the database and pushed it back up into the azure environment onto the same server I put my empty database when testing 9.4.4. I've updated the web config in the source to point at the destination database copy. I'm planning to FTP the existing site files over on top of the clean 9.4.4 installation in the webapp.

Is there a guide out there for working through common pitfalls with this approach? 

I really really appreciate the support. Again - thank you so much for replying!

I am really no Azure expert and never did this but have you seen this blog post:

https://www.dnnsoftware.c...-as-an-azure-web-app

Absolutely! That's the guide I've been using to get everything over into Azure. Thanks for the link!

I successfully FTP'd the files over on top of the installed DNN. Now I'm getting a 500 error. The 500 being recorded is very similar to what this user posted: https://www.dnnsoftware.c.../azure-setup-issues. Where does DNN write logs? Any advice on path forward?

I updated the connection string to my database in the web config to point to the appropriate server/database in the Azure environment. Are there any other locations that have to be changed? Would migrating the data on top of my clean install database (using generated insert statements) be helpful?

Is there a guide to getting an existing DNN site up and running in Visual Studio for local debugging? If I can get a debugger around it and generate some meaningful/useful error messages I can start solving my issues.

This is my first experience with DNN - I apologize for the barrage of questions!

Thank you

Dnn logs errors in the portals/_default/logs folder like Will said, you will see runtime logs and upgrade/install logs in there.

From what I heard on azure you may need to bump up some resources to avoid timeouts or some such for upgrade/install and then you are OK reducing them. But again I am no azure expert so really not sure.

If this issue is azure specific, debugging a local install won't help.

No appologies needed for questions, sorry I can't be of more help on azure though, I never ran such setup.

Thanks for the reply!

The log file for today in that directory is empty even after hitting 500's on the site:

No bytes are being written there. Is there a config file elsewhere that could be pointing at the wrong place?

It would be useful to know what the specific 500 error(s) is/are.

Regarding any specific steps for migrating, there really aren't. You do the same things you'd do in any other hosting environment. Just in the case of Azure, you use different methods. For example, moving the database is not the typical backup/save/copy/restore method you may be used to. Instead, you may be creating a temporary database in Azure SQL and use SSMS to move the database (which is faster, actually).

The other trick I use is when I need to clear out a folder. I find it easier and faster to use the built-in Console blade in Azure to delete the site using the command line, versus FTP.

Also, when uploading a site to restore, use 7zip to package up the site using 7z Ultra compression, and then copy the 7zip executable to upload a single backup file and then run a single command line to unpack it. (Another time-saving trick.) 

I got it running!

Turns out my FTP client failed to move over all of my files and failed silently. After I got them accross, I turned on detailed errors in the web config and found some additional problems with that file referencing directories that do not exist on the target server. Removing those references allowed the app to load.

Thank you again for the help!