Web Analytics Report readers know that one of the biggest issues about Omniture SiteCatalyst is the complexity of the implementation. Former HBX customers (now part of the Omniture stable) are finding that SiteCatalyst is a significantly different tool because of the amount of customizations required.

Migration becomes a double-edges sword: you can get more functionality, but you have to work harder at it, and you may lose out on some of the things you liked about HBX, such as tagless campaigns. Although I hear reports of HBX customers leaving Omniture forCoremetrics' and WebTrends, there still seems to be a lot of interest in simply staying the course and enduring the migration.

As I've argued before, if you have a contract coming up for renewal, use this as an opportunity to check your requirements and test the waters.

However, if you want to go for the migration and you'd like to get a vendor-neutral take on how to deal with Omniture's ins and outs, I recommend taking a look at the Implementation Toolkit for SiteCatalyst published by Semphonic, the firm I work with. It's comprised of 6 parts: Implementation, Best Practices, Migrating from HBX to SiteCatalyst, SiteCatalyst Coding Standards for Flash, AJAX and DHTML, a Project Plan template and Functional Spec template. It's written for web analytics managers who are actively involved in HBX to SiteCatalyst migrations, SiteCatalyst administrators, and CMS managers and application developers who need to make sure that data is collected properly for Omniture SiteCatalyst.

As always, whether you plan to migrate or are considering another option, make sure you have figured out not only your metrics requirements, but whether stakeholders are actually using the data you're providing. I see too many situations where reports are simply thrown over the fence to stakeholders and they have to figure it all out on their own -- a waste of time and resources, whether you're using a free solution, like Google Analytics or Omniture.