Al Nyveldt

Adventures in Code and Other Stories

BlogEngine.NET Provider Migration

If you are interested in switching your BlogEngine data from XML to a database or the other way around.  This page will give you everything you need to do the job in the best way I know of.

Important Notes:

This process will only be transferring your Blog posts, pages, settings, and ping services.  It does not transfer particular extension or widget settings and it doesn’t transfer over your users.  Once you do the transfer, you will need to set these back up manually by logging with the default admin user (password: admin) and making changes.

The steps described are for an intermediate level .NET developer.  A little BlogEngine experience will help, but is not required.  If you have no idea what a web.config file is or a connection string, you will most likely not be successful.  You’ve been warned.

This process is not officially supported as part of the BlogEngine.NET project, but is something I’ve used quite a bit personally.  I have made a few changes to make it work universally however.  It likely could be made a bit easier, but configuration is really the only tough part and I’m not sure how to improve that out of the box.

1. Backup

We are going to need to make some changes to your web.config file as part of this process, so you’ll need to make sure you back that up, but I’ll go ahead and recommend you back up everything just in case you do something crazy in the middle of the process.

2. Check Version

This process is only for people who are using BlogEngine.NET 1.4.5 or greater.  In addition, you are strongly recommended to get the DbProvider Patch and install that as well.  (It is only for Database users, but you are either moving from or to a database so this means you.)

3. Set up the new provider

This is the tough part of the job.  We need to edit your web.config to set up your new BlogProvider.  The process varies depending on your current data source and your destination data source.

If you are currently using XML and want to move to a database:

This is an easy set up.  I’d recommend following the instructions in your Setup folder to prep your blog to run on the database of your choice.  When you get it set up, you will see the welcome post.  Then, you can go back to the web.config and change the defaultProvider in the top of the blogProvider section to “XMLBlogProvider”.  This will bring your blog back to where it was before you made the change and now you have your DbBlogProvider set up to the database you want to use.

If you are currently using a database and want to move back to XML:

You are extremely lucky, because you can skip this step. 

If you are currently using a database and want to move to a different one:

This is the most painful choice, but not too bad, especially if you understand the basics of the Provider model.  We are simply need to make a second DbBlogProvider entry with a different name.  It will point to a different connection string which will point it to a different data source.  In addition, if you are not just change SQL Server databases, you’ll need to add the appropriate web.config entries to configure BlogEngine to work with the new database.  You’ll also need to install the needed dll file in your bin folder.  You will find more information on this in the Setup folder of your blog.

<BlogEngine>
    <blogProvider defaultProvider="XmlBlogProvider">
        <providers>
            <add name="XmlBlogProvider" type="BlogEngine.Core.Providers.XmlBlogProvider, BlogEngine.Core"/>
            <add name="DbBlogProvider" type="BlogEngine.Core.Providers.DbBlogProvider, BlogEngine.Core" connectionStringName="BlogEngine" />
            <add name="NewDbBlogProvider" type="BlogEngine.Core.Providers.DbBlogProvider, BlogEngine.Core" connectionStringName="NewConnection" />
        </providers>
    </blogProvider>
</BlogEngine>

I’d recommend changing your defaultProvider to the new one to make sure you have it set up correctly and once you get the welcome post, you can change it back to see your blog again.

4. Clear out your destination

You need to delete the data in your destination Provider otherwise the migration will fail.  If you have a database, this means you can run a script that looks something like this:

DELETE FROM be_PostCategory;
DELETE FROM be_PostComment;
DELETE FROM be_PostNotify;
DELETE FROM be_PostTag;
DELETE FROM be_Posts;
DELETE FROM be_Categories;
DELETE FROM be_Pages;
DELETE FROM be_Settings;
DELETE FROM be_PingService;

If you are moving data into XML, you’ll want to clear out your App_Data\Posts folder and your App_Data\Pages folder.

Be sure not to delete your existing blog data by accident.

5. Install the BlogMigration page

Download the BlogMigration zip file, extract the 2 files included and copy them to the admin\Pages folder of your blog.

6. Open the BlogMigration page.

You can now surf out to your blog, login, and then go to BlogMigration page by typing in the appropriate address.

7. Run it

Select your destination BlogProvider from the dropdown and click the button.

This may take a few minutes, but you’ll get a notification on the screen when it is done.

8. Change your default BlogProvider

If you got through the above steps, you can now open your web.config file and change the BlogProvider section defaultProvider to the destination Provider.  Browsing out to the site should bring it up using the new provider. 

You can optionally remove your old data if you’d like after you are sure everything is working properly.

9. Update your users, extension, and widget data

As mentioned above, you’ll need to set your users back up and change passwords.  Also any extension and widget data is lost and will need to be re-entered.  Other than that, you are done.

Troubleshooting

I’ve run across an occasional problem with the tool in the many times I’ve used and they are have always revolved around three things.

1. Make sure your new destination provider works.  If you can’t switch your defaultProvider to the destination and see the default page, this will not work. 

2. Make sure you clear out the data in the destination before you run it.  If you try to add a duplicate record in a table, it will fail.

3. I have had a few occasions where a data field in my destination database wasn’t big enough to hold the incoming item.  In these situation, you simply need to expand the field size, clear the destination, and run it again.

Support and Improvements?

This is not an official part of the BlogEngine.NET project.  As I mentioned earlier, it is simply a bit of code that I used for my own purposes (read: testing and paid consulting work).  It is something I get at least one email a week asking about so I am making it available for everyone.

If you find a flaw or have an improvement on my process, I’d love to hear about it.  It time allows, I’d be happy to publish the update.

About

BioPic Hi. My name is Al Nyveldt and I'm a software developer from central Pennsylvania, USA.

I'm on the BlogEngine.NET development team and write on a variety of development related topics. More...

Follow me on Twitter
Contact me via email

Recent Comments

Quote of the Day

"Go to the ant, you sluggard! Consider her ways and be wise,"

- Proverbs 6:6

Sponsor


Recommended Books



Archives


Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2008

Sign in