Approach and execution of

migrating an MS SharePoint site

into Liferay

Senior Project Manager

A How-To Guide

Alistair Oldfield – Emeldi Group - Official Liferay Partner

Agenda

• Introduction • Summarize topic: Approach and execution of migrating an MS

SharePoint site into Liferay

• Description of Environment

• Illustrate some of the challenges

• Migration of a SharePoint site to Liferay

• Migration of content

• Migration of functionality (Web parts -> Portlets)

• Evaluation of realized benefits

• Automated

• Repeatable

• Re-Useable

Approach and execution of migrating an

MS SharePoint site into Liferay

SharePoint 2007

.NET

Web Parts

Liferay 6.0 Java

Portlets

Source Environment

• Legacy Portal: Microsoft SharePoint 2007

– Roughly 50 web-part applications (.NET) • Highly customized behaviour

• Integrated to back-ends and other services (Google Maps, etc.)

– Thousands of pages, articles & documents

• Objective: The existing content must be integrated

(iframe, proxy portlet) with or migrated in the new Liferay

portal solution.

• Decision: Completely decommission legacy portal and

fully migrate (port) content and functionality into Liferay.

Different Technologies & Concepts

Many different approaches to dealing with various concepts

Cannot migrate “ALL” data kept within a MOSS database • Not necessary

• MOSS data doesn’t always map into Liferay concepts

Focus on what’s important for a site: • Pages & site map

• Layouts

• Articles / Content

• Documents

• Images

• Theme / style

• Web Parts

Requirements

1-to-1 migration of a SharePoint site from visitor’s point of

view

Automated Migration • Huge site with 1000s of pages, manual content migration not viable option

Repeatable Migration • Repeated across DEV, ACC, PROD

• Can redo in case of we need to fix something

Re-useable • To be re-used for other MOSS-driven portals in other migration projects

Offline • Snap shot of MOSS DB can be stored in an export package which can be then used

as repeated input to imports at a later time

Approach

Requirements can be satisfied using an export/import

approach:

•Web Part attributes

•CMS

•Libraries

Inspect MOSS

•XML schema

•Export

•Content

•images & documents

Export data into package

Liferay Services &

API

Import to Liferay

Migration Overview

Migration of Content

• Full export of MOSS content

into XML package

• Implementation of importer

application using Liferay

services

Migration of Functionality

• Complete re-implementation

of .NET Web Part

applications to JSR-286

compliant portlets

Migration of Content - Layouts

MOSS Web Part Page • Page

• Layout

• Custom data (per page)

• Web Part Zones

• Web Parts

Liferay Portlet Page • Page

• Custom Fields (common for

all pages)

Liferay Layout • Layout (including drop

zones)

• Portlets

MOSS Content Structure

• Webs/sub-webs

• Default Page/Pages • Layout

• Content Type

• Web Parts

• Libraries

Implement Liferay “Importers”

1. LibraryImporter

2. WebImporter

3. PageImporter

4. LayoutImporter

5. WebPartImporter

Web

Default Page

Pages

Layout Content

Type Web Parts

Web Libraries

Documents Images Lists Other Libs

How MOSS export/import works Export MOSS into an export package:

Inspection application traverses MOSS structure and exports data to an XML &

media files into a ZIP package (also indexed in XML)

Each XML element is mapped to an importer class

Ex: <page> -> com.emeldi.moss.liferay.PageImporter

Import the export package into Liferay:

1) First Pass: Import libraries using Liferay API

• Documents into Liferay Document Library

• Images into Liferay Image Gallery

• Remember URLs of all imported docs/images (needed later)

2) Second Pass: Depth-first recursion through

exported elements: • Invoke corresponding “importer” classes

Site is built from the bottom-up

• Child elements (webs, pages, etc.) first

• Parent elements last

WebImporter

Depth-first recursion through

exported elements: 1. Invoke page importer for <default-page> element for

that web (next slide)

2. Recurse until leaf web is encountered

3. Invoke page importer for all <page> elements within

that web (next slide)

4. Return up the stack until root web is imported

PageImporter

1. Using Liferay API create the page

2. From exported MOSS page data (from content-type, etc.) assign:

• Title

• URL

• Custom fields

• Meta data

• Etc..

3. Remember the page URL for later

4. Based on exported MOSS page layout data, perform a look-up against a

Layout Importer mapping and invoke the resolved LayoutImporter (next slide)

Page

Layout Content

Type Web Parts

• Layout X Importer Layout X

• Layout Y Importer Layout Y

• Layout Z Importer Layout Z

LayoutImporters 1. Specialized Importers based on a given page layout

2. Assigns layouts to a page

• Target Liferay layouts must be manually created prior to migration

• Approximations of MOSS layouts

• Similar MOSS layouts can use the same Liferay LayoutImporter

• WebPart X Importer WebPart X

• WebPart Y Importer WebPart Y

• WebPart Z Importer WebPart Z

2. Identifies the MOSS web content and Web

Parts which are located in each drop zone.

3. For each drop zone: • performs a look-up against a Webpart Importer mapping

• places the corresponding Liferay portlet into the drop zone

(next slide)

• invokes the resolved WebPartImporter (next slide)

WebPartImporters 1. Specialized Importers based on a given MOSS Web Part or web content

2. Each MOSS webpart must have a corresponding Liferay portlet (JSR

168/286) implemented prior to migration (java approximation): • MOSS Web content Liferay Web Content Display Portlet

• MOSS custom FAQ Web Part Custom implemented FAQ portlet

• etc..

Example 1) Importing of an FAQ Web Part:

• MOSS inspection application knows which FAQ Web Part data is necessary to export and exports

it into XML package

• FAQImporter knows how to read this data and insert it into the target application database and

portlet preferences

• FAQ Display Portlet is created and placed into the Layout drop zone

Example 2) Importing of web content (administered HTML markup): • MOSS inspection application exports HTML markup

• Markup is filtered/re-written (next slide)

• WebContentImporter creates a journal article with filtered markup

• Web Content Display Portlet is created then placed into the Layout drop zone

Markup Filtering/Re-writing

• Remember the first pass (storing of library URLs)?

• Remember the storing of page URLs (on page create)?

Here is why: • All migrated MOSS markup still has links to legacy MOSS pages and media

(library files)

• These URLs no longer exist in Liferay - now imported into Liferay sitemap,

Document Library, and Image Gallery

• Markup must be re-written before inserted into Journal Article:

<a href=“/Web/Library/doc1.pdf” /> <a href=“/documents/12034/doc1.pdf” />

String transformations performed for: <a>, <img>, <javascript>,

<object> tags

Challenges SharePoint List imports • No such feature in Liferay which captures same functionality

• List data transformed into: • Liferay native data (journal articles)

• Custom application data

Non-automated portions of the migration • Theme & Layouts

• Custom Portlet implementation (porting of .NET into Java)

Content Issues: • Legacy style support (may consider manual cleaning)

• URL re-writing

• HTML tidy • Remove MS bloat from MOSS markup

• &amp; (HTML correction)

Summary

SharePoint inspection application exports all needed data

into XML and ZIP packages

Liferay Import application imports packages into LR using

both Liferay and custom APIs

Custom SharePoint Web Part applications must be ported

into Liferay-deployable portlet applications

Legacy SharePoint URLs must be re-written during import

Result

• Fully automated SharePoint-to-Liferay

Content Migrations – re-useable for other

installations/ projects

• Repeatable across all environment pillars

• Re-useable for future use in other

SharePoint-driven portals

Benefits to the Liferay Community • Migration from SharePoint to Liferay an often recurring question

for organizations considering a move to Liferay

• We have demonstrated that a re-usable tool exists which allows

for:

• Fully automated content migrations (pages, images, content, etc.)

• Establishing a foundation for introducing ported custom applications

from .NET into Java

• Emeldi has now opened the path allowing organizations to

transition from legacy SharePoint applications into Liferay:

• Economically

• Quickly

Project Reference ČSOB:

Established in 1964

Diversified

bancassurance groupoffering complete

product portfolio to all client segments

Long-term leader in

many segments, esp.

financing of housing needs and mutual

funds

Active in the Czech Republic

Member of KBC Group

Slovakia

ČSOB

ČSOB

Poisťovňa

Czech Republic

ČSOB

ČSOB Pojišťovna Hungary

K&H Bank

K&H Insurance

Belgium

KBC Bank

KBC

Insurance

Bulgaria

CI BANK

DZI Insurance

About the Emeldi Group

• Emeldi is an official Liferay

service partner in the UK,

Czech Republic, & Slovakia

• e-Commerce / Self-Service /

best practices

• Specialized expert team -

Liferay hands-on experience

• Flexible development

process & methodologies

• Innovation is one of the key

differentiators

2

2

• Specialized in delivering

large-scale portal

solutions to Tier 1

enterprises

Thank you Open for Q&A

Alistair Oldfield – Senior Project Manager Emeldi Group – Official Liferay Partner

alistair.oldfield@emeldi.com