You know what – Commerce 9 is released. OK, I’m just kidding, it was released 6 months ago, in October 2015. Last week, Commerce 9.12 was released, and at this time of writing, Commerce 9.13 is on the oven just released. So it’s not so new – but with 6 months on the field, I think Commerce 9 has proven it’s stable and production-ready to be your next version. If you are looking for an upgrade to your website, Commerce 9 is the obvious choice. Many customers have successfully upgraded their sites to Commerce 9 – and the results have been very encouraging.
But it does not mean that upgrading is easy. Commerce 9 is undoubtedly a big upgrade, and getting there is not just an easy walk. So how to ensure a successful upgrade?
Plan ahead:
The catalog subsystem was rewritten almost entirely in Commerce 9, resulting in some very big migration steps. Depends on the size of your catalog, it can take from a couple of minutes, to hours (I would not be too surprised if it takes a day). So plan for the possible down time (even though in most cases you will be upgrading your site in staging first).
Commerce 9 is also a major release, so there were breaking changes – you will have to fix some of your code, to make it compiled. The amount of code that actually broken should be small, but it’s better if you check this list http://world.episerver.com/documentation/Items/Upgrading/EPiserver-Commerce/9/breaking-changes/ to see how much works you’ll need (tips: the less you use “internal stuffs”, the code you’ll have to change. The internal stuffs are, by convention, marked with special doc tag.).
Backup everything and take small steps.
It’s never too much to take a backup. Or backups. And databases are not enough – you should also back up your entire site, including files and folders, and your assets.
If you are currently at previous version than 8.x, I would recommend you to do upgrade in small steps – upgrade to the next major version first! If you’re at Commerce R1 SP1 (which is quite old, by the way, and you have my high-five for going through the long way to get there), make sure to upgrade to Commerce R3a, then Commerce 7.5, then Commerce 8, and finally Commerce 9. Back up your site before upgrading, upgrade it, check if everything is working as expected, then back up again. Raise and repeat until you reach Commerce 9.12. (No, I’m not asking you to upgrade to each minor versions, but major versions). Theoretically, you can upgrade a Commerce site from 7.5 to 9.12 directly, but I personally think that’s not a good choice. If anything goes wrong (and something will), you’ll never know which step you missed or something was broken. Trust me, you won’t want to go through all the step again.
And one important thing that you should do: after each major version upgrade, export your catalog and store the file in a safe place. Why? Each upgrade has SQL scripts and migration steps to update the data of catalog. In most of the cases, they work as expected, but there are edge cases when one of them fail. In such case, it’s fastest to just import the catalog from previous version and let the API:s do the job. Of course, that means abandoning the non-published versions, but if you don’t care about versions, it’s the easiest way to ensure your data is in good shape if something goes wrong.
Before upgrading to Commerce 9
There are certain settings which affect the migration steps in Commerce 9 which you should care about:
- The name of the catalog metaclasses. If you use the default naming conventions (which mean the node metaclasses have prefix CatalogNodeEx_ and entry metaclasses have prefix CatalogEntryEx_ (which will be in case they were created in Commerce Manager, or certain API:s), then there is nothing to worry about. However, if you have custom names (which is almost an edge case, because you must have used a very specific method), make sure you are upgrading to at least 9.10. 9.9 and earlier were affected by a bug which makes those metaclasses not properly migrated. If upgrading to 9.10 is not an option (I don’t think it should be a problem, but well, you know better than me), then you’ll have to make your hands dirty:
- Change all of your metaclasses which do not have the convention prefix in table MetaClass
- Change the actual tables which stored data of those classes
- Run exec [dbo].[mdpsp_sys_CreateMetaClassProcedureAll]
Now the migration steps should run successfully.
- The DisableVersionSync flag. When this flag is enabled, then all of the versions except published ones will not be migrated. If you don’t use versions at all (for example, your site updates entries via PIM connector), or you just don’t want to carry versions to Commerce 9, this can be a good option to reduce the time of migrating contents.
- The ecf:DraftMigrationBatchSize appSettings – this specifies how many versions will be migrated in one batch – the default value is 5000, but you can adjust this number to match with your server – if it is fast enough, a bigger value can make
After upgrading to Commerce 9
Now with your hard works, your site is upgraded – nuget packages were installed, the breaking changes in code were fixed, the project can now build, and update-epidatabase ran successfully. Congratulations! Time for a beer, or two. Or may be not yet. We still have works to do – to ensure the site works as it should:
- All migration steps are completed. From Commerce 8.16, the migration steps are mandatory and there is no trick to skip them, but you still should make sure that all migration steps are completed before doing anything else – such as opening Commerce Manager.
- All catalog contents and version are migrated – simply open Catalog UI and check for a random entry to see all the properties are there. Note that depends on your catalog size and the number of versions you have – it might take a while for all the versions to be migrated. There is a scheduled job, named “Draft store migration job”, which will do the migration silently and disable itself after complete – if it was not there, it does mean that the migration steps are done.
- If you turned on the DisableVersionSync just to skip the migration of versions, make sure the CatalogContentDraftStore has been properly cleared. If it hasn’t, try to delete the remaining rows. It will take a while, but one of the customer reported that cleaning the CatalogContentDraftStore reduced the CMS database size from 12GB to 3.5GB – so it’s worth it.
- Shink the database size. A lot of changes are made with the migration steps – so a call to DBCC SHRINKDATABASE can yield some good results.
When everything is done, backup your site again. And finally have a beer for your hard work!
