https://www.youtube.com/watch?v=i0djbZqIuWI -- emeldi.com

1. 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

2. 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

3. Approach and execution of migrating an
MS SharePoint site into Liferay
SharePoint
2007
.NET
Web Parts
Liferay 6.0
Java
Portlets

4. 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.

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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 ImporterLayout X
• Layout Y ImporterLayout Y
• Layout Z ImporterLayout Z

14. 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 ImporterWebPart X
• WebPart Y ImporterWebPart Y
• WebPart Z ImporterWebPart 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)

15. 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

16. 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

17. 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)

18. 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

19. 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

20. 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

21. Project Reference
ČSOB:
Established in 1964
Diversified
bancassurance group
offering 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

22. 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

23. Thank you
Open for Q&A
Alistair Oldfield – Senior Project Manager
Emeldi Group – Official Liferay Partner
alistair.oldfield@emeldi.com