I blogged before about my new hosting account with Applied Innovations. Here is an update on how that new adventure is going.
Tonight I began making some of my preliminary adjustments and staging of files. I began with getting familiar with the control panel used by Applied Innovations, Helm. Despite the popularity and widespread adoption of Helm, this is my first time ever using it. I had many problems finding settings and getting started with the control panel, but that is very little fault of the host. Even though they manage the control panel, all of the short comings and difficulties I experienced had to do with Helm itself.
One of my first steps was to use one of their temporary URLs to install and stage my new DNN installation. Through my investigation of my options in their control panel, I noticed two things to note for other DNN’ers. First, the shared hosting account limits you to SQL Server 2005. This is not a big deal, unless you’re a bleeding edge of technology kind of person, in which case you’d want 2008. Second, their auto installer for DNN limits you to the latest 3.x release, and version 4.03.04. For serious DNN’ers, this is hardly adequate, as we are currently at a stable DotNetNuke® version of 4.09.03 (about to be 4.09.04), and version 5.01.00 is right around the corner.
Since we are limited to version 4.03.04, I obviously chose to manually install my DotNetNuke® instance, which like any other host is very much allowed. All you have to do is a combination of remote SQL Server management (method varies by host), and file uploads through FTP. Mitchel Sellers does a great job of walking you through this. I suggest checking out his blog.
The most basic steps that I needed to perform were: (1) back up the original sites’ portal directory; (2) generate a portal template of the original site; and (3) install the same DNN version on the new host. While the original site version is currently 4.09.02, I plan to upgrade it to version 5 as soon as possible. Unfortunately, migrating any site is not that simple. Throw in the variable of the site also being a dynamic one such as DotNetNuke®, and the complications become multiplied.
When you use dynamic modules such as the blog or forums module, there are many ways to migrate their data. The most basic, and easiest, would be to simply export and import data, though this is typically not an option with a shared hosting account. Therefore, the chosen solution will greatly depend on how your shared host allows you to manage and view your data. As a last resort, you can generate your own SQL scripts, or use a module that pulls the data for you.
I have actually been multitasking, and performing some of these steps while writing about them. One thing you might know about some of my sites and included modules, is that I occasionally modify them. A perfect example is the DNN Blog Module. I have added a little extra something to my version (which I have blogged about in the past). In doing so, I have had to recompile the original project, generating a new DLL to upload. If you don’t already know, replacing the DLL will recycle the application. The end result is that the application needs to do all kinds of things: reload all DLLs into cache, reload DNN cache, and many other things. This new environment allows this to happen than most hosts so far. Their hardware must be beefy, and well-managed.
Well… That’s it for tonight. I need to stop blogging, and find a good stopping point.