How to use Content Porter effectively to move Pages with lots of linked content

Question

I would like to use Content Porter and move Pages from a Dev environment to a Production environment. The pages are for regression testing and we're in the process of restoring our Production DB over our Dev DB, and the developers would like to keep their regression content set.

Until now Schemas and Templates have been developed in the Development environment and tested against a minimal content set, then moved to Acceptance, tested some more, and finally into Production. Development contains about 5% of the content as Production - mostly Folders, Structure Groups, Schemas, and Categories / Keywords.

We have some heavy Pages that use Metadata fields to link to a variety of Components, and these Components link to other Components, etc. And of course we have images and keywords there for good measure.

Life started 1.5 years ago in Dev with Schemas and sample content, but since then the Production content has never been moved back to Dev.

I've attempted many combinations of dependencies on both the export and import, minimal and everything, on both sides, selecting the Pages as the item to export / import. With the export everything and all dependencies I got 465 dependent items on about 8 pages. Yes, that's true.

When importing I either get 4 pages of failures on import all, or I get a partial update of 4 items, all of which are Structure Groups.

Maybe I am missing a magic combination of export filters and import filters? Usually I start with Schemas, then Components, then Keywords, and then Pages. I've tried a bit of this, but without the knowledge of how the content is built up, I'm a bit in the dark with which items are underneath these pages.

I was able to do an export / import of some other less heavy pages.

Answer 1

I don't know whether the Content Porter will cope with something of this complexity, or indeed how to choose the right configuration, other than to say - go ahead - switch everything on and let it roll.

If that doesn't do it, then probably your next best bet is to try it in zero-dependency mode. In other words, switch off all the dependency management in Content Porter and manage the dependencies yourself. This means, of course, that you must manually ensure that all the dependencies are present.

One common way of doing this is per publication, doing schemas first, then templating, and finally content. (And of course, both importing and exporting follow this order.) This is a traditional method from before Content Porter became able to do the right thing in the blueprint, but it's still a reasonable way to keep things tidy. Alternatively, you can put everything in one package and switch on the blueprinting support.

Managing the dependencies manually isn't too hard, but it can take some trial and error to get it right. The trick is always to save the configuration file of your export. If your import fails because of a missing dependency, you load the configuration, fix the problem in the export, and go round again.

Recent versions of Content Porter generally manage to cope as long as the dependency item is either already imported, or is present in the package.

As you've mentioned, knowledge of how the content is built up is a huge help. Ideally, if you foresee having to do this again (and re-importing production data is a likely scenario), you should try to maintain the export definitions during development. (In other words it becomes a development task, and your definition of done includes "being able to successfully re-import your test set") If you can successfully export/import from dev to test, you have a reasonable chance of being able to do it from dev to dev.