jRQL ideal suited for project migration

If you need to migrate structures, assets, pages and content from existing MS projects into any other target, I can recommend using jRQL for it, if you have Java know-how. I used it myself very successfully in the relaunch of hlag.com in 2009 and my daily work.

As you maybe know a typical migration is not working in an one big export – one big import scenario. From my experience it rather goes iteratively for well structured bunches of pages in addition with manual building of a new project.

I want to share 3 possible ways of migration I used jRQL successfully in the mentioned relaunch. I translated this picture from my jRQL presentation into English.

Highest possible flexibility
For all scenarios it is true, that you have the most possible flexibility, because you can customize your migration in standard Java with all possibilities you have within. This maximum of flexibility therefore matches every need you have, which is not possible with every kind of export import tool.

Handling source data inconsistencies
Everybody has experienced or can at least imagine, that the source data are often not as consistent as needed to handle it by a program. This is especially true, if authors work on this data rather than a typically well structured administrator.

From my experience I therefore first get in touch with the source data to get an impression of the quality. I log it simply into the Eclipse console and make the program as robust as needed. You can imagine this migration as an iterative process rather than a write and run once approach. Typically I handle the data exceptions within my program (or manually in old project) until the output is acceptable. jRQL supports this iterative approach very well, because it offers high level functions instead of bothering you with the bits and bytes of raw RQL.

And even you created new pages within the new project which are not correct jRQL helps you to get rid of them and start over again. Within the jRQL plug-ins you can rely on the plug-in Reset all draft pages to make your page creation/updates not happen at all. Usually I empty my Tasks within the new project before I start the creation/update in the new project (program runs with my logon guid and session key) to make this work smoothly.

After this general aspects, let me give some more details on each of the scenarios with it’s strength and weaknesses.

Scenario 1: Copy on-the-fly
This approach is best used if only less conversion of content is needed in between. I used it for copying the press releases pages from a non-language variant project into the new project which uses language variants. The migration program therefore covers the structural differences of source and target project.

In addition I fixed several errors in the HTML code within my program, because some text editor functions are not available in the new project. A migration log collects all pages where this automatic patching did not work for manually re-work.

Scenario 2: Export, correct and import
This scenario is perfect if another person is needed to correct the data before importing them in the new project. Of course there is the flexibility to collect and prepare the data from page elements in old project to be able to write them in line by line fashion into an Excel tab file format (*.tab). jRQL offers the handy class TabFileWriter for this purpose.

Of course you can use only the second half of this scenario to create a bunch of pages from the data contained within an Excel file. I use this approach often in my dayily work with the system, because it’s much faster to enter all needed page details into an Excel sheet than using the slowly MS SmartTree or SmartEdit interfaces with it’s tons of clicks needed.

Scenario 3: Migrate assets
This scenario needs some additional explanation how it works. In my example I used it to migrate vessel certificates (2 PDFs per vessel page) into the new project. But it’s of course possible to use it for migration images.

The steps needed are as following:

  1. use jRQL for every page and download the asset (jRQL supports downloading assets from media and image elements)
  2. save them locally with the unique identifier for each page, in my case I used the unique vessel name. As a positive side effect all assets are named by a unique style, what authors only seldom do unfortunately.
  3. copy the whole folder with all assets to the MS server machine
  4. use the function Import assets on the target folder and refresh attribute values by using Update asset manager too
  5. use jRQL and get the unique page identifier back from the filename, in my case simply the vessel’s name. Find or create the target page and set the filename into the image or media elements of this page

Please have in mind, that jRQL download the assets from the RedDot ImageCache. Unfortunately this is not always up-to-date, but usually this is much more comfortable than doing it manually with several mistakes either.

Post a comment or leave a trackback: Trackback URL.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: