Open Mic Webcast:Web Content Management Migration - Best practices and planning for Migrating deployments

© 2014 IBM Corporation
Powered 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 Sydney
leeberry@au1.ibm.com
Anuradha Chitta – WCM and Portal Support, ISL India
anchitta@in.ibm.com
Vinayak Tavargeri- Support Manager – Facilitator for AP Open Mics
vtavargeri@in.ibm.com

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 place
Whether 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 / Export
A 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 / Export
Live Content Yes Yes
Drafts Yes No
Version History Yes No
Projects Yes No
Deleted Items Yes No
User Profiles (Categories & Keywords) Yes No
Portlets & Settings Yes No
Resource Environment Yes No
WebSphere Variables Yes No
Other Portal Features Yes No
Other 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 Syndication
WCM 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 Process
The 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!

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 been
performed, and then an ongoing cross version
syndication relationship is maintained
The new site shares design artifacts from the
existing site, yet it can launch independently
of 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

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 Portal
http://twitter.com/IBM_ICSSupport

Open Mic Webcast:Web Content Management Migration - Best practices and planning for Migrating deployments

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (14)

Mehr von Vinayak Tavargeri

Mehr von Vinayak Tavargeri (7)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Open Mic Webcast:Web Content Management Migration - Best practices and planning for Migrating deployments