2012.10 Oldfield
- 1. Approach and execution of migrating an MS SharePoint site into Liferay Alistair Oldfield – Emeldi Group - Official Liferay Partner September 2012 A How-To Guide
- 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 • & (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 – Project Manager Emeldi Group – Official Liferay Partner alistair.oldfield@emeldi.com