With the advent of SDL Web 8.5, we’ve seen many nice improvements to the software. We’re able to move items in the blueprint hierarchy, we can now set up a whole content delivery environment with a number of powershell scripts, … but in our most recent upgrade, we’ve found a big problem.
I recently worked with a small team within Content Bloom to migrate over 200 gigabytes of binary files into SDL Web. Actually it was 244 Gigs to be exact ☺
It was quite a learning experience and I wanted to share some of that learning.
We have a number of environments that we work with and we move data from one environment to another using both the generally available and highly customized Release Manager and, of course, the Content Porter. This post is about what we’ve found that works best in this scenario, and helps us to ensure that the release happens as smoothly as possible.
With the release of SDL Tridion 2013 SP1, we get a lot of new functionality. One of the interesting features I found was the ability to decommission a Publication Target. This feature is added to the Core Service, and currently not directly available from the UI. Which sounded like a good exercise to make a UI extension, with which you can call this new method.
An SDL Tridion schema is the (.xsd) definition for content. Eventually you may need to re-order, add, or remove fields to accommodate changes to your content model. Changing a schema doesn’t instantly change content based on this schema (trust me, you probably wouldn’t want it to). To make such an update, authors can open and close items in the Content Manager Explorer which will synchronize components to their updated definitions.
This works for a few dozen items, but can quickly get monotonous for several hundred components. Per SDL Live Content (http://sdllivecontent.sdl.com/), SDL Content Porter 2009 and later have the ability to “Synchronize Components against Schema before importing.”
“If you import a Component or a content item that has metadata, without also importing the (Metadata) Schema on which the item depends, the item you import may not match the Schema on the target system. Selecting this option tells Content Porter to attempt to modify the import item to match the Schema found on the target system.”
There’s a very important note that “selecting this option could lead to data loss.”
This synchronization option covers field re-ordering, removing fields no longer in the target schema(s), and adding new fields as long as they’re optional and/or have a default value. Also important is realizing this is a synchronization action which makes some existing fields match an updated schema. It should be clear that things like renaming fields and requiring a field without a default would require more manual (or programmatic) work.
The option is selected by default on an import, all you have to do is update the target schema before doing the import. Again, be careful with this as schema changes can lead to data loss.
“Synchronize content against Schema before importing” is selected for you during imports
The question is simple: “How to say goodbye to your migration tool?”, the answer could be diverse. Dump it in the trashcan, store it in a safe, pay its bill, but my favorite one is: “with a handshake”. Now some of you might wonder what I’m rambling about, so let me explain myself.
I’ve just recently written a script which imported a load of content from flat files into Tridion. Using the flat files, the script creates the various folders, pages and components etc that it needed. Unfortunately I cannot share the code as the client contract permits me to do (plus it was a throw-away tool written specifically around the format of the import data) but I can share a couple of titbits that I learnt about item naming and WebDAV lengths.