Today's post is one that has been on the sidelines since RTM.  I've gone back and forth many times on whether to discuss Import/Export and, more importantly, how to best present the story.

First and foremost, I want everyone to realize information in this post is based on personal experience derived during the march to RTM.  I've shared my opinion in person with several MVPs (some prior to RTM) and various clients and field experts over the past year.

There is only 1 feature set in WSS/MOSS that I will not use or advocate using.  The feature set is Import/Export (aka PRIME).  Fundamentally, I believe the area to be too fraught with bugs and weird behaviors to trust my data to the API.

Did you ever see the Micheal Keaton movie Gung Ho?  It's a movie about an embattled factory trying to stave off closure by meeting an impossible deadline of a bazillion cars (or something close to that).  The feel good moment came when the factory team was able to meet the deadline by throwing together something that looked like a car.  Sure it looked like a car, but it could barely standup on its own.  It was nothing that you would ever trust your life to, much less drive it around your neighborhood… well, the Import/Export feature set is that little car with parts falling off left and right.

To help you see why and how I came to this conclusion, let me share a story…

Everyone is probably very familiar with how products are built.  You build, test, fix bugs, and repeat the last two steps until you get to a point where there are few bugs.  Think of a plane landing, with a smooth 3 degree glide slope.  You start high, but eventually you land smoothly.

PRIME was the exact opposite.  It was a plane in a nose dive. 

In the months leading to RTM, features are locked down - development (in theory) is complete, only code changes are bug fixes.  Everyone is testing the product in weird and arcane ways trying to find the showstoppers.  Testers spend days looking for hard to reproduce bugs, they jump across feature areas trying to see how well all pieces of the puzzle integrate.  The days of finding easy design bugs were over months, if not years ago. 

PRIME was exactly the opposite.  Core development was still happening up until the last days before RTM.

Why?  It was broken.  Really broken.

I happened to stumble on the feature set in late August.  It was a fun new feature set that promised a lot of functionality and I had the perfect test case - this site bluedoglimited.com.  Look around and you will see that my site is composed of three sites (root and 2 child sites), utilizes a mixture of customized and OOB pages, where lists are displayed with mostly with LVWP and DVWPs. On a scale of 1 to 10, with 10 being a super customized site, I would say that my site was a 2 or 3.  In other words, I would never consider this site to be anything more than a standard SharePoint site with some minor tweaks.  This site should have sailed through the tests.

Import/Export could not handle the simple task of exporting, then importing any of my sites (either the entire site collection or even a single site).  Keep in mind that RTM was scheduled for mid-November.  Starting in the August time frame, a lot of energy was spent trying to get Import/Export to work against my site.  For nearly 2 months, bug after bug was found.  It was a painful process, if there was a way to stop the process from working - we ran across it. We went from not being able to even complete the export process, to not completing the import process, to any variation in between a broken site, page, list, web part, etc.

In late September, I stopped looking at Import/Export.  I was never able to see any of my sites work through an entire Export and Import process. I wrote a letter that I had never written in the nearly 7 years at Microsoft.  My recommendation was to cut Import/Export from the RTM product even though we were less than a month and half away from RTM.  I shared my frustrations with my lead and the lead responsible for Import/Export.  I suggested that we cut the entire Import/Export API to ensure that we didn’t ship a core platform area wasn't working as designed.  If it couldn't deal with my simple site, how did we expect it to work against other more complex sites?  In my view, it was our responsibility (WSS) to ship the best API possible.  We could pull the entire feature set, redesign, test, and bake perhaps by SP1 or at worst by v4 release Import/Export to the world.  I wanted us to ship something that worked and would not introduce a ton of PSS calls.  We needed to get it right, not just ship it.

In the weeks following, many hard and heated discussions were had.  There was a strong push to have the feature set removed.  The bug count was astronomical, the feature was broken, the core engine had been rewritten just a month prior with the hopes of making the final run to RTM smoother but such a move had introduced just as bugs as it was trying to avoid.

The sticking point was that the CMS team relied on the Import/Export functionality.  So pulling the Import/Export API would have killed  the their story.  The net result was that a partner team needed the feature set and therefore the core WSS Import/Export team was stuck between the proverbial rock and a hard place.  Cut it and another key feature is also killed, or keep it and deal with the issues associated with shipping a faulty API.

In the end, there was a huge list of "oh yeah, you can't do that" items on a whiteboard.  In theory, each one of those items/bugs should have made it into the documentation explaining the limitations of Import/Export.  I haven't verified if those issues were documented - simply because I knew that I would never use, recommend or be involved in a project that required Import/Export.

So what types of problems do you encounter?

• All personalizations are completely lost
• Various customizations are also lost
• Sites based off v2 site templates are not handled
• During import, files are dropped due to the blocked items list
• There are wacky versioning and security issues

The biggest problem is the simple fact this area is bound to have a variety of undiscovered bugs.  The problem here is really two fold…

1. Without full realization of the problem, there is no way to effectively log the condition as an error in the ULS logs.  It's not like you can go the logs and get a complete list of "things to fix", you will have to find them the hard way - reviewing each page, webpart, list, etc.
2. Something that is not apparently broken today, may show up tomorrow… long after the import… and the relationship between an error introduced by the Export/Import process is lost (i.e. you believe the problem is the result of some other change).

The best analogy that I can give you is an onion - there are many layers of problems.  I can't even begin to think of the mess that would result from multiple iterations of Export/Import further munging your data. 

Bottom line is that import/Export cannot preserve my data from one instance to the next.  As a content owner, I need a means by which data can be rapidly exported and imported with 100% fidelity.  I can't copy, move or even archive my data with Import/Export.  As was seen in the march to RTM, Import/Export treads a line that is too delicate. Anything beyond a basic site makes it impossible to rely on the feature set. 

Why do I say that?  My data is important.  Without it, I don t have an operational site.  I have no time to chase down the differences between the original and newly imported sites.  The current Import/Export mechanism ensures that I will not be able to carry my data forward in fashion that is remotely close to the original form.  This is bad.  This is exactly why I won't use or recommend using Import/Export.

Side notes:

1. My experience was isolated to the Site and Web levels only (i.e. actions available via stsadm.exe).  I was told the granular single list item (aka cherry picking) import/export functionality was in better shape.  I have never utilized/verified cherry picking.
2. In the defense of Import/Export, some of the problems we ran across were upgrade bugs.  PRIME was in fact a good upgrade testing path.  Nonetheless, once those bugs were fixed, there were still plenty of prime-specific bugs.