What it takes to migrate content-based websites into a fully powerful InsiteCommerce solution

Consider a situation where a company has several business units, all of which need a new web presence within a similar theme.  One of those business units is ready to transition its website into a full-service eCommerce platform, however, the other units are not quite ready yet.  This situation is one that XCentium has encountered, and the solution was to create content-only InsiteCommerce websites for the sites that weren’t yet ready for eCommerce with the plan to one day merge them into the InsiteCommerce solution we created for the site that was ready for an eCommerce presence. 

As simple as it seems, the day came to begin merging these content-only Insite solutions into one that has an established ecommerce architecture and there were some fires to put out.  I’d like to go over some of the measures that were needed to take to combine two existing Insite solutions, as well as document some of the challenges we faced in the areas of managing Content, Settings, and Code.

Content

The biggest task involved in migrating one instance of Insite into another is copying over content from the source database to the target database.  For some tables, it’s as easy as that- copy everything from the source table into the target table.  With others came some difficulties.  It is important that a record exists in the target database’s Website table in order to provide an associated WebSiteId GUID for the source database’s website. Any pages and related content created through the CMS basically exists in three tables in the InsiteCommerce database:

• Content
• ContentItem
• ContentItemField

The records in these tables need to be moved into the new database, however, it is likely that the main identifier for ContentItem records, ContentKey, has already been used in the target database.  To resolve this, we find the highest used ContentKey in the target database, and update the records from the source database to begin there.  This means that any field referencing a ContentKey from the source database needs to be updated with the new ContentKey.  Through several SSIS packages we were able to add the existing content from the source database using newly generated ContentKeys.  This came with a few setbacks:

1. Some widgets, such as navigation lists and linklists, save the associated ContentKeys in a Byte array.
   1. To resolve this, we needed to decode the byte arrays and reencode using the updated ContentKeys using SSIS.
2. Templates created in the CMS do not have an associated Website.
   1. If the templates differ from website to website, it is typically necessary to add the templates created from the source website.  These templates might share names with templates in the target solution, which warrants that the names are changed.  For our client, we prefixed the template names with the website name in order to differentiate them from website to website.
   2. In the CMS, all templates that have been created for the solution will show regardless of the website that is currently browsed.  Since templates are not website specific they are shared across all websites that are part of the InsiteCommerce solution, and can be created/modified/deleted regardless of which site the CMS user is currently on.

Settings

Other than the tables relating to content, other tables are necessary for successful migration of an Insite database.  Depending on your situation, you may or may not need to migrate data from these tables relating to Administration:

• ApplicationMessage
  • In Insite 4.2 this area is called “Messages” in the Admin Console. They include Website Targets meaning you can associate a WebSiteId to each record in the table.  It is likely your two websites will share identical values for Message, in which case you can leave the WebSiteId value blank to allow the message to pertain to all websites in the solution.
• ContentManager
• ContentPageState
• CustomProperty
  • The CustomProperty table houses values for custom properties on many different Insite entities.  In our situation, this table pertained mostly to the custom properties that we set on Dealers, allowing for dealer hours, images, and various other properties.
• Dealer
  • As Dealers, or “Locations”, are added through the Insite Console, their information generated dynamic pages.  This information is not housed in the Content tables and needs to be migrated separately.
• EmailList
  • Email lists are website specific, so if the source website has information on email lists it needs to be copied over.
• EmailTemplate
  • Email templates, if different across websites, need to be copied over and the name value should be prefixed with the website name to prevent naming conflicts from site to site.
• HtmlRedirect
  • Any 301 redirects set up for the source site should be copied straight over to the new solution.  Since the table simply has OldUrl and NewUrl there should be no difficulties in copying these records directly to the target table.
• Promotion
• SearchTermRedirect
• WebSiteConfiguration
  • Website configurations are the settings that are set up specifically to one website.  As long as the WebSiteId field is mapped to the id of the source website id these records should be copied completely without issues.
• WebSiteCurrency
• WebSiteLanguage
• WebSite
  • A record for the source website must be present before copying most the tables above to provide an associated WebSiteId GUID as stated prior.
• WebsiteSitemap

Code

In our situation, the source databases and websites we were moving were from an older version of InsiteCommerce (4.1.0.19726) to a newer one (4.2.0.28152).  This resulted in changes needed for any custom code created for the source website to work well in the target site’s newer codebase.  Some items that may have been effected are:

• Custom pages, widgets, directives created for content
  • Through variants of Insite, the markup for some of the most useful CMS tools has changed quite a bit.  It may be necessary to update using statements, namespaces, model names or other items that might have changed in items customized for a specific website in the code.
  • With Insite 4.3, a fair amount of the markup for Website Themes has been upgraded to the DotLiquid templating system.
• Custom typescript files
  • It’s possible that typescript class names or variables have changed.  It may be necessary to check that custom typescript files are still compiling correctly with the same intention as the target solution.

Conclusion

While the task of migrating existing content-based InsiteCommerce solutions came with some hiccups, the learning experience involved resulted in a detailed set of steps that lead us to be able to rerun the task over and over gaining traction each time.  Once introduced to a solution with existing eCommerce functionality, the source website can share all the necessary tools created for the initial target website in areas such as integration, search functionality, complex pricing, and product configuration.  In the end, we have made it possible for clients with multiple business units to create a uniform look and feel across their properties with the possibility to gradually introduce each unit to a full-bore eCommerce solution.