Migrating content from filesystem to database without deleting them from the filesystem

Question

We have a website that uses static content from Tridion published to the filesystem. We are working on changing it over to a DD4T website with content from Tridion being published to the Database. There are 26 site publications and 100’s of components and pages in them. Most of the sites publications are language specific with translated content in them.

We plan to do a phased in migration of the website, so that a portion of the website is migrated to DD4T while others are still served by the filesystem (within a given publication). We will handle which parts are served by the filesystem and which parts are served by the database via web server configuration that will direct the request appropriately. But we have an issue: How can we publish the updated pages to the DB while still keeping the old page in the filesystem for a particular publication?

Since our existing content broker is still serving the pages from the filesystem to the customer while we are developing them in DD4T and publishing them (before redirecting the URL to go to the DD4T application that will serve them), we need a way to publish the updated pages to DB while still keeping them in the filesystem. But if we simply update the cd_storage.xml for the publication to change it from the filesystem to the database and then publish content, the content will be removed from the file system while being added to the database.

So again, the question is: How can we publish the updated pages to the DB while still keeping the old page in the filesystem for a particular publication?

Answer 1

If I have understood your question correctly, then you want to have parts of your site served via DD4T (from the broker database), whilst other parts will continue to be served from your existing (mainly file system based) site.

Assuming that there is no issue with the content being duplicated on the filesystem as well as in the databases (and it sounds like this is sometimes desirable (e.g. for images)), then you should consider setting up another Deployer, dedicated to the DD4T sections, that writes Pages and Components to a new Broker database.

You can update your existing Publication Target(s) to write to both the existing Deployer (that serves the old file system sections), and to the new DD4T deployer (that writes everything to the new Broker database).

Then (assuming that your two parts of the site are served by separate web applications) you can then configure the DD4T part of your application to read the DD4T XML from the Broker database, whilst the older parts of your site continue to have their cd_stroage_conf.xml file configured to read from the file system.

Everything that your editors publish will then go to both locations.

As you move your site over to DD4T, you will serve less and less content from the filesystem.

Once your whole application has moved over to DD4T, and all of your content has been published in to the DD4T Broker database, you should be able to remove your old filesystem deployer (and remove it from the Publishing Target(s)).