open mic webcast:web content management migration - best practices and planning for migrating...

© 2014 IBM CorporationPowered by IBM SmartCloud Meetings

Web Content Management Migration - Best practices and planning for Migrating deployments

2 © 2014 IBM Corporation

About Us

Lee Berry - Systems Architect, WCM Lab, ADL [email protected]

Anuradha Chitta – WCM and Portal Support, ISL [email protected]

Vinayak Tavargeri- Support Manager – Facilitator for AP Open [email protected]


Agenda:

Overview Migration Paths Migration Best Practices Migration modifies your data in place Library Import and Export Syndication in the migration process Cross Version Syndication Managed Pages considerations Planning for changes to content during migration Q&A


Overview Plan

─ Most of your time needs to be spent in planning your migration.

─ Standlone or cluster, Local or Remote ─ Hardware and software prerequisites─ VP considerations and much more..

Prepare─ Prepare your Source and Target environments according to

migration guidelines Migrate and Customize

─ Make sure your custom themes and skins and custom apps are working with the newer specs

─ Migrated elements are not automatically upgraded to use features that are available in the new version.

─ Taking advantage of new features that were not available in the earlier portal requires extra attention after migration is complete.

Validate─ Make sure post migration tasks are completed and your

source and target server look and behave similar. Deliver


Migration Paths

Supported Paths: 7.0 → 8.5 8.0 → 8.5 6.1 → 8.5 (Not supported) Migration is not supported across editions:

– For example, – WebSphere Portal Enable Version 7.0.x → WebSphere Portal Enable Version

8.5,– WebSphere Portal Express Version 7.0.x → WebSphere Portal Extend Version

8.5

Migration is supported only from the two latest fix pack levels for any listed offering. So if you don't have the latest fix pack then install it before moving forward.

You cannot upgrade the source portal with a fixpack after migration if you intend to re-migrate the JCR.


Migration – (Do's and Dont's)

Migrating between different operating systems is not supported. For example, – Windows → Unix (Not supported)

You can migrate from an older version of an operating system to a newer supported version of that operating system, or from a 32–bit version of an operating system to a supported 64–bit version of that operating system

Migrating between different Databases is not supported– Source DB2 → Target Oracle (Not supported)

Cell Name and Node Name needs to be same to avoid application deployment issues during migration.

Migration to Empty portal is not supported.

Disable Automatic Synchronization


Migration – Best Practices

Plan your migration well - PLAN, PLAN, PLAN...

Ensure that you install the latest available fixpacks and cumulative fixes on both the source and target servers.

Backup your database and file system.

Disable JCR text search on both source and target servers during migration.

When migrating WCM, remove any locks to prevent issues at a later stage of migration.

Search collections need to be exported and deleted on the source, which are to be imported into target server once migration completes.

If WAS Pre/Post Upgrade task is running into OOM, please use this option to increase the heap:

– -javaoption -Xmx1024m



Reduce the size of your JCR DB by deleting unneeded content versions and history.

JCR Database schema has been revamped in 8.0+– Less number of tables, uses WIDE tables which are READ optimized.– Dynamic table creation is replaced by rows in WIDE tables.

Maintain the health of the DB for better migration performance.– Oracle - Disable auto space advisor task to prevent deadlocks during migration– DB2 - Increase transaction logging space as needed.

- Run reorgchk and runstats for better query execution plans during the migration process

Restart migration from where it left off with -Dwp.migration.framework.resume=<resume point> Example: -Dwp.migration.framework.resume=deploy-portlets

For troubleshooting, use -DskipCleanup="true" to preserve work folder– If using both parameters, make sure to clean the contents of

wp_profile/ConfigEngine/config/work/ folder



Managed Pages is enabled by default on a fresh 8.0 and 8.5 install of Portal. If you are migrating from Version 8.0, managed pages is automatically enabled after you complete migration.

If you are migrating from Version 7.0, managed pages is automatically disabled, and it is recommended to enable managed pages after migration to take advantage of new features, such as - syndication and versioning of pages, and the ability to manage pages in projects

In Version 8.x, if the name of a web content library is the same as the URL context of a virtual portal, you can experience incorrect rendering behavior. To prevent this issue, rename the library to a different name before you perform the migration.

Automatic syndication is disabled during migration. Validate the syndication pairs before resuming syndication on the target servers.


Migration modifies your data in placeWhether you are performing a remote or local migration


In Place Migration

In 6.0, all data was exported from one server and imported into another From 6.1 the Release & JCR domains are migrated in place

Migration irreversibly alters the data in the connected database─ This is the database that the migrating server is connected to

Absolutely ensure you are migrating a clone of your production database


In Place Migration – What can go wrong?

Problem Prevention Cure

Upgrading the production servers database

Don't connect the migration server to the production database. Ensure that migration doesn't have the privileges to alter production data, or that it cannot even make the connection to the production instance

Shut down production and restore the production database from backup

Restoring more than the JCR domain during post migration data update *

Verify that your restore procedure is only affecting the JCR instance

Migrate again

Failed backup or restore procedure

Practise the process before commencing migration

None, data is lost.

* Post migration data update requires the JCR domain to be restored to the latest image of the previous versions data... some customers have inadvertently reverted the migration of other database domains by restoring them at the same time


Library Import / ExportA popular choice in migration, but is its popularity deserved?


Library Import / Export

Import / Export is designed to archive and share design libraries It was never designed to be a general purpose migration tool

You can import libraries from earlier releases─ Subject to limitations described on the next slide─ Version matrix matches supported migration paths─ Generally two major releases e.g. 6.1 → 8.0

Import / Export is much slower than migration─ Since it must save and restore every single field in the system─ In place migration is selective about the data it updates

Despite the limitations, Import / Export remains a popular choice!


Library Import / Export - Limitations

Migration Import / ExportLive Content Yes YesDrafts Yes NoVersion History Yes NoProjects Yes NoDeleted Items Yes NoUser Profiles (Categories & Keywords) Yes NoPortlets & Settings Yes NoResource Environment Yes NoWebSphere Variables Yes NoOther Portal Features Yes NoOther Application Server Features Yes No


Library Import / Export - Warning

The popularity of export and import stems from its simplicity It only requires one infocenter section to describe!


Library Import / Export - Warning

The popularity of export and import stems from its simplicity It only requires one infocenter section to describe!

However, it can be dangerous! There is the potential for data corruption if

care is not taken with referential integrity


Library Import / Export – Referential Integrity

Library Import / Export is designed to share design libraries which generally have only inbound references (no external dependencies)

Export will export all references... However, Import can only import references which can be resolved at the

time of the import The process will complete, but the references will be cleared

Recommendations Use migration or cross version syndication instead! Import & export ALL libraries together


Cross Version SyndicationWCM migration has never been easier!


Cross Version Syndication

Only available on 7.0 and newer Follows the same supported paths as migration Replaces the “post migration data update” procedure Can be used to migrate web content only

─ Slow because every item is syndicated separately─ Or you can migrate initially to speed things up

Functions exactly the same as syndication between servers of the same version─ The behavior is determined by they syndicator, so for example 7.0 to 8.5 will function the same

as 7.0 to 7.0. So new syndication features or behaviors will not be exposed

You can choose to syndicate live items only, or all items, so there really is no good reason to use import / export (from 7.0 onwards)


Syndication in the Migration ProcessThe infocenter describes how to migrate a single cluster, but how should we tackle the migration of a multistage

syndicated deployment?


Syndication in the Migration Process

When migrating a deployment with syndication we don't recommend migrating each server individually

Rather migrate the upstream syndicator and use syndication to propagate changes


Syndication in the Migration Process – Data Update

A key concept in syndication is that it relies on the syndicator and subscriber agreeing on the identity of every item

Now we have cross version syndication, data update is only for 6.1.x sources 6.1.x → 7.0 also supports web content only migration 6.1.x → 7,8.x migration process does not deterministically preserve identity

So...

After data update from 6.1.x all downstream subscribers need fresh rebuilds– This means a clean database– Otherwise duplicate items (drafts, versions) will be found on the subscribers– Fortunately the syndication process can be accelerated by copying the JCR domain– <plug>On 8.5 a rebuild after copying the DB is much faster than 8.0</plug>


Managed Pages Considerations



Pages live in the Release database domain as they always have All features but syndication continue to use the pages from the Release domain Syndication is possible because WCM stores a copy of each page in the JCR

The copy is syndicated, and the subscriber restores the release copy This means that the portal site library can be deleted and rebuilt easily



Migration should be performed with managed pages OFF But you can easily enable or disable it, so if you need to re-migrate a system

with managed pages, you can disable it, migrate then re-enable

Incidentally you could rebuild a portal site structure from a site library by syndicating it to another portal



Now because syndication relies on the agreement of identity you must be very careful not to perform operations on downstream portals which could result in pages or applications with different unique ids

This means ALL pages and applications should be deployed on downstream systems using the Staging to Production process described in the infocenter

Failure to observe this caution will result in syndication errors

Which is a fantastic segue to plug the new 8.5 syndication administrative UI

http://www.youtube.com/watch?v=gW-21QOF35U

Which includes a full featured diagnostic console, watch the video!

http://www.youtube.com/watch?v=gW-21QOF35U


Planning for changes to content during migration

Cross version syndication introduces the possibility of staging the migration by migrating teams and projects separately



In this example, an initial migration has beenperformed, and then an ongoing cross versionsyndication relationship is maintained

The new site shares design artifacts from theexisting site, yet it can launch independentlyof the migration of the rest of the organization



In syndication upstream changes overwrite downstream modification─ Unless the downstream system has a more recent modification─ This is a temporary state, as soon as the upstream item is modified it will overwrite the down

So, make changes upstream wherever conflict is possible Limit downstream work to isolated libraries where no upstream modifications

take place


References

Portal 8.5 Knowledge Center ─ http://www-01.ibm.com/support/knowledgecenter/SSHRKX_8.5.0/mp/migrate/migration.dita

Portal 8.5 Migration Roadmaps─ http://www-01.ibm.com/support/knowledgecenter/SSHRKX_8.5.0/mp/install/rm_migration.dita

Portal 8.5 Managed Pages─ http://www-

01.ibm.com/support/knowledgecenter/api/content/SSYJ99_8.5.0/wcm/wcm_config_mngpages.dita?locale=en&ro=kcUI

Staging to Production─ http://www-01.ibm.com/support/knowledgecenter/SSHRKX_8.5.0/mp/deploy/dep_intr.dita

Cross Version Syndication─ http://www-01.ibm.com/support/knowledgecenter/#!/SSYJ99_8.5.0/migrate/mig_content_options_cross-

version.dita

Recommended fixes─ http://www-01.ibm.com/support/docview.wss?uid=swg27007603

http://www-01.ibm.com/support/knowledgecenter/SSHRKX_8.5.0/mp/migrate/migration.dita

http://www-01.ibm.com/support/knowledgecenter/SSHRKX_8.5.0/mp/install/rm_migration.dita

http://www-01.ibm.com/support/knowledgecenter/SSHRKX_8.5.0/mp/install/rm_migration.dita

http://www-01.ibm.com/support/knowledgecenter/api/content/SSYJ99_8.5.0/wcm/wcm_config_mngpages.dita?locale=en&ro=kcUI




http://www-01.ibm.com/support/knowledgecenter/SSHRKX_8.5.0/mp/deploy/dep_intr.dita

http://www-01.ibm.com/support/knowledgecenter/SSHRKX_8.5.0/mp/deploy/dep_intr.dita

http://www-01.ibm.com/support/knowledgecenter/#!/SSYJ99_8.5.0/migrate/mig_content_options_cross-version.dita



http://www-01.ibm.com/support/docview.wss?uid=swg27007603

http://www-01.ibm.com/support/docview.wss?uid=swg27007603

32 | © 2014 IBM Corporation

Thank you Q & A

Visit our Support Technical Exchange page or our Facebook page for details on future events.

To help shape the future of IBM software, take this quality survey and share your opinion of IBM software used within your organization: https://ibm.biz/BdxqB2

IBM Collaboration Solutions Support page http://www.facebook.com/IBMLotusSupport

WebSphere Portalhttp://twitter.com/IBM_ICSSupport

http://www.ibm.com/support/entry/portal/scheduled_tech_exchanges/software/lotus/lotus_brand_support_(general)

http://www.ibm.com/support/entry/portal/scheduled_tech_exchanges/software/lotus/lotus_brand_support_(general)

http://www.facebook.com/WebSpherePortalSupport

http://www.facebook.com/WebSpherePortalSupport

https://ibm.biz/BdxqB2

http://www.facebook.com/IBMLotusSupport

http://twitter.com/IBM_ICSSupport

open mic webcast:web content management migration - best practices and planning for migrating...

Software