Migration Tool vs Updater Script

[Josh Suarez]

Hello

I need advice from the community on a content namespace migration.

We're using Hippo 7.9.7 Enterprise.

I have requirements to move existing document and image content to a new jcr namespace we are now creating.

This content namespace migration involves

1. Existing document types are being moved to a new namespace

2. and in addition these existing doc types are having un-necessary properties removed

3. And (the big part) existing document and image content needs to be modified to use the new doc types/imagesets in the new namespace

I see two possible options to do perform task #3 above: 1) use the migrator tool to change existing content nodetypes/properties in place or 2) use several updater scripts to just copy the existing content into the new doc type in a new location in the jcr.

I've read through the documentation for Namespace Migration [1] but I'm concerned about this limitation of the migrator tool:

The migrator tool cannot be run in a live cluster. Make sure all repository nodes are down and the migrator is the only agent operating on the database.

If I understand the wording correctly, it appears we would have to shut down our site's repositories while we run this migrator tool on our database?

Bringing the repository cluster down would effectively shut down our sites so this option does not seem to be ideal from a business perspective.

In addition, because we don't host our CMS we'd need to coordinate running the migration tool with our hosting company for both the testing phase and the final release.

I'm leaning towards the updater copy scripts option but I wanted to ask the community if using this migrator tool has additional benefits compared to just running a few updater scripts to perform content copy operations.

And I'm very open to hearing about any other options out there.

Thank you,

Josh

[1] http://www.onehippo.org/library/upgrade/namespace-migration.html

[Jeroen Reijn]

Hi Josh,

yes, you are right and have understood the consequences correctly. 

However what we sometimes also see is that our customers have an editorial content freeze on production. Then they create a copy of the DB and move that to for instance the staging or acceptance environment, after which they run the migration tool and copy over the migrated DB to production again before they startup the environment on the new database. It's a little bit of a hassle, but that works as well.

The migrator tool was mainly introduced because before Hippo 7.8 (or 7.7 I can't really recall anymore) we had strict nodetype definitions. They only way to remove a field was to run such a migration, which was always a pain. Now we have a relaxed model and this is much easier, so I'm also curious what your corner case is that you will need the migration tool.

Are you changing supertypes of nodes or some similar use case or do you just want to introduce some new namespace or nodetypes?

Jeroen

--
Hippo Community Group: The place for all discussions and announcements about Hippo CMS (and HST, repository etc. etc.)
 
To post to this group, send email to hippo-c...@googlegroups.com
RSS: https://groups.google.com/group/hippo-community/feed/rss_v2_0_msgs.xml?num=50
---
You received this message because you are subscribed to the Google Groups "Hippo Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hippo-communi...@googlegroups.com.
Visit this group at http://groups.google.com/group/hippo-community.
For more options, visit https://groups.google.com/d/optout.

--

Jeroen Reijn
Hippo

Amsterdam office - Oosteinde 11, 1017 WT Amsterdam

Boston office - 745 Atlantic Ave, Eight Floor, Boston MA 02111, United states of America.

US +1 877 414 4776 (toll free)
Europe +31(0)20 522 4466
www.onehippo.com

http://www.jeroenreijn.com | @jreijn | http://about.me/jeroenreijn

[Josh Suarez]

Hi Jeroen

Thank you for your reply.

...so I'm also curious what your corner case is that you will need the migration tool.

I'm only in the research stage at the moment and I'm unsure if we need the migration tool or not for this work.

I'll speak to the bigger picture which might shed light on what we're trying to accomplish.  Our company has multiple brands with their own independent development teams which would all like to use Hippo.  We currently have only one brand that has gone live with a Hippo MVP solution which currently uses a single common generic jcr namespace for everything.  Because each brand uses common terms which have slightly different meanings between brands, we're already seeing cases where node types names will be overlapping between brands.  Rather than manage a central common namespace for everything we want each brand to be completely independent and free to modify their own namespace.

To that end, the goal is to move the one live brand's existing jcr node types into a new brand specific namespace so their node types do not pollute the common generic namespace.  Each additional brand would likewise get their own namespace as they are on boarded leaving the common generic namespace for limited use for a few things that are truly common across the organization.

Are you changing supertypes of nodes or some similar use case or do you just want to introduce some new namespace or node types?

Getting back to the use case which may or may not require the migration tool.  I'm looking for a way to remap this one live brand's existing content "in-place" in the repository.  This remapping would move the content out of the common namespace and into the brand's new namespace.

In other words, I want to change the primary node type and the super type of existing nodes in the repository if this is possible.

If this is not possible, plan B is to just perform a content copy rather than an in place transformation.

So I think the answer to your question would be both.

Thank you again for your assistance.  It is greatly appreciated.

Josh

[Josh Suarez]

If anyone is interested, I was able to perform the existing document migration using a groovy script to update the documents in place.

Changing the primaryNode type was not an issue.

[Mahesh Acharya]

Thank you for the update.

> --
> Hippo Community Group: The place for all discussions and announcements about
> Hippo CMS (and HST, repository etc. etc.)
>
> To post to this group, send email to hippo-c...@googlegroups.com
> RSS:
> https://groups.google.com/group/hippo-community/feed/rss_v2_0_msgs.xml?num=50
> ---
> You received this message because you are subscribed to the Google Groups
> "Hippo Community" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to hippo-communi...@googlegroups.com.
> Visit this group at http://groups.google.com/group/hippo-community.
> For more options, visit https://groups.google.com/d/optout.



--

Mahesh R. ACHARYA
Solution Architect | Mobile: 781-640-5559 | Email: m.ac...@onehippo.com
Boston - 71 Summer Street, Boston, MA 02110
Amsterdam - Oosteinde 11, 1017 WT Amsterdam

US +1 877 414 4776 (toll free)
Europe +31(0)20 522 4466

http://www.onehippo.com/