Migrating current website to dotnetnuke.

Question

Is it tedious to migrate an existing website to DNN? Will starting from scratch be a better idea?

Answer 1

Hello, I migrated a 150 page website last year and it was not tedious.

We sat down with DNN, planed out the structure we wanted and build the menu's - 1 hour Then we opened Notepad, and spent three days copying and pasting. Copy from Live Site, paste to notepad, and CTRL +A and CTRL + C, flick over to DNN and paste again. Any complex or arkward pages my colleague left for later. After three days we had migrated the entire site. No tools, no fancy import and export.

All done in a couple of days. And of course by the end of it, my colleague was up to speed on DNN also.

It is a low tech, highly successful and easy approach.

I would consider import routines for highly structured data, but otherwise, I recommend this approach.

Answer 2

You'll essentially need to recreate the site, and yes it will be tedious. Once you have some of the structure in place, you'd need to recreate the pages, assuming they are simple content pages.

However, if you have a typical data-driven .NET application with a lot of server-side code and data access, you'll have to redesign a lot of it to fit into DNN.

Regardless, if you want to maintain your existing user list, you'll probably have to write a new DNN membership provider to interact with that list. If you were using the default ASP.NET membership tables already, this should essentially be done for you, because that is what DNN uses internally by default to, although it does wrap it with it's own membership provider interace, because their users have to pretend be to portal-specific (even though they really are not).

Hopefully a lot of your code is in user controls and classes. If so, you can probably wrap them in DNN containers. It will be tedious and require a lot of bug fixes, but it's doable.

If your code is instead a bunch of spagetti spread out across a bunch of pages, you'll probably have to make a lot of changes to get them into DNN containers.

You'll have to decide what to do with your existing database. Will you merge it into the DNN database, or will you keep it seperate. The seperate idea is nice because it keeps the DNN presentation junk away from your core functionality, but bear in mind that your users/roles/permissions will also be in the DNN database, so you may lose that link to your legacy data.

Which leads to roles and permissions. DNN uses the standard ASP.NET role provider interface, but it's not really that simple. Even if you provide your own role provider to integrate with your own roles, you'll still need to persist the roles and user/role assignments to the DNN tables because it's not perfectly abstracted.

... and there are I'm sure a bunch of other things specific to your situation that I can't think of.

Anyhow, you'll probably end up somewhere in the middle. You won't find some magic migration utility that will port your stuff right over, but you probably won't have to re-write every line of code either. Depending on the size and complexity of your site, you'll probably need to do a lot of analysis, using some people with DNN expertise, to figure out a solid plan.