Why use a SharePoint migration tool when you can upgrade using the built in upgrade methods? Maybe you want to skip 2007 going from 2003 to 2010, or get out of your MOSS enterprise and move into Standard or even WSS. Maybe you want to get out of a site definition or template or from one language template to another. Another reason to use a migration tools is if you already built a rock solid 2010 deployment and just want to get the data moved in. May be you’re finding that moving data on your own with the import or export is changing dates and making you “own” everything… Built in upgrade is designed to get from point A to B, without transformation. But transformation may be your goal.

That’s just a start. I’m sure you’ll find even more reasons, like co-existence, control, more management interfaces, and flexibility. However, if you choose to upgrade with 3rd party SharePoint Migration tools, it’s important to track down a few things about your migration vendor. Here are a few suggestions:

1. What version is the tool?

Many SharePoint tools are on their third and fourth versions moving into a very mature system.

2. Maturity in the field – Seasoned?

What is the usage experience with your favorite systems Integrators/consultants? With an ecosystem that includes full fledged support and deployment services? More mature tools may have agreements with partners as resellers or even provide motivation. I encourage you to try to understand if it’s a certification or if it’s a reseller program. Some tools are easier than others, and you don’t want to get stuck trying to run a complex tool by yourself if you’ve got a day job. Migration is very common outsourced project they can be expensive not just for the tool but for the services, so spending time may pay off. That said, cheaper doesn’t mean better.

3. Microsoft Gold Certified?

When I first started drilling into the migration tools I found there are really 4-5 common tools used for SharePoint migrations, but both new vendors and traditional ECM vendors have been moving into the space putting everyone into a position where it’s time to look again. Even your mature vendors are revisiting their tools with SharePoint 2010. Even if they aren’t listed [in the directory] as having a SharePoint migration tool, they are likely waiting on the launch wave and testing to make their announcements.

4. Time to migrate/Reliability.

One consideration your firm should think about is the time it can take to migrate. Some content will be easier than others, but throughput for large migrations like a SharePoint to SharePoint or a FileShares to SharePoint, the time to accomplish your migration can become critical and a major factor in your requirements.

5. Unique features such as Co-Existence.

You may or may not find features like coexistence where both can exist in production for some period of time. Flushing out these types of requirements can definitely help you better decide what is important.

6. API Compliance.

On the source there’s an API (the Application Programmability Interface) and the destination. The more you work with the SharePoint API, the more you’ll understand it’s got it’s quirks. If you’re migrating applications and state into SharePoint you’ll find limitations in the API. How does the vendor come up with creative solutions to overcome these? Ever run an export and import and wondered why you lost your alerts, workflows, recycle bin, last modified date, and more. So what is the vendor doing to overcome these limitations? You’d be surprised to know if they are using FrontPage RPC or pushing the data into the database with some level of their own support. The more you know… If you care, these are the questions you should ask.

7. Exception Handling.

What is your tool doing to allow you to see what its dropping and to handle exceptions? One of my favorites for testing a tool is to add common file names that SharePoint hates. Add an ampersand & in your file name, add something in parentheses, add a few dots and then try to migrate. You get the idea. Does it crash, does it fail, does it allow you to change the & to and? Can you say, yes forever? That’s serious usability. Also dig into the interfaces.

8. For whom is the UI Design.

Definitely not all of these tools are created equally. Some are designed for developers, some for engineers, some for end users. Huge differences. In the case of Notes for example, you may be looking to take an application and move it to a simple template or to simply mirror the functionality. How does the tool help you analyze your needs and map them? How much intelligence and how much does it require you to do the heavy lifting vs. trying to encourage the right thing? You should also ask if you as a customer can run this tool or will it require a trained expert or certified consultant.

9. Involvement in Technology Adoption Program (TAP) and Partner Council.

While not every company can be in the SharePoint 2010 TAP program, it does give them a pretty good head start on working with the new technologies. It also frequently reflects the relationship with Microsoft. Microsoft does have its favorites. In the case of things like Notes, Microsoft can be very motivated. Explore that motivation, they may be interested in helping you in more ways than one including some services.

10. More than Migration: It’s not about Point A to Point B.

You might be surprised when you analyze it, but the best tools provide the best options for what you can do between the source and destination from sites and site templates, to content types, and meta data. Even more. Migration time is the best time to reconsider your information architecture, your security structure and inheritance, and to simplify, or to even go more structured. You know your needs better than the tool, so how does it expose the right features for you?

11. How complex is the installation and dependencies?

Is this tool run on both sides, on a third party client? How much hand holding does it need? If it’s hard to install and you need a big book to run it, you’re likely going to wish you had a consultant helping you.

12. Does it support automation?

Has it been updated with PowerShell or at least have a way to batch script automate? Sometimes it’s nice to have UI, and other times it’s nice to jump to the command shell.

13. Some tools are built with Java, others with older versions of .NET.

Do you care? You may have data center standards or require special requirements around ensuring security requirements being met. Something to consider.

14. Migration to and from Hosted environments.

Understand your destination. You may be looking at your source and miss the point about getting it into the source. If it’s a site in the cloud how are you going to get the data there? SharePoint Designer? BPOS D may have you run the tool on your side and have you give them a database. This may mess with your coexistence plans.

15. Who else is using the tool?

Be sure to get customer references and if you’re putting some money into the tool, you may want to actually talk to them. Don’t buy a tool based on the cool website. You have to at least make sure it works. Buying tools on sites happens these days, but often you’re laying down some serious cash, so, do your due diligence and read a case study or two.

Joel was the first dedicated SharePoint Administrator ever. He's been working with SharePoint nearly 11 years and worked at Microsoft in both IT and the product teams including architecting the first roll-out of Microsoft's own global intranet.

You can jump start your brand-new SharePoint 2010 Knowledge Managment and Social Networking by an auto-tagging follow-up after migration based on taxonomies:http://www.layer2.de/en/products/Pages/Auto-Tagger-SharePoint-2010.aspx