Best Practice Guide for a Successful Migration

Transcription

1 Best Practice Guide for a Successful Migration

2 Overview This document is designed to assist you in managing a successful migration project using Tzunami Deployer. The document contains recommendations that will facilitate your migration and guides you through the steps of the process, from: analyzing the source content, to planning your migration, to the final step of performing the actual migration. This document is presented as a list of best practices that we recommend in order to help you maximize your mastery of the tool for a fast and efficient migration. Our support team at Tzunami Inc. is available to assist you at all times. Please submit any questions or queries to support@tzunami.com. We look forward to hearing from you. Sincerely, Tzunami Support Team Page 1

3 Phase 1: Source Analysis Understand your Source Analyze Plan Model your Target Migrate your content Deploy How many items do you have in the source? Prior to the actual migration phase, it is important to get a sense of the size of the source data that you plan to migrate. Valuable considerations include: total size of the data to be migrated and an approximation of the average file size. It is also important to consider the fact that the security, versions and metadata associated with each item add to the size of the data. Which items do you have in the source? It is recommended to know how many files/folders and other types of items you are planning to migrate. How are the items organized in the source? In addition, you must know what items you have in the source. It is important to understand how these items are distributed in the source hierarchy. Identify complex issues within the source system Since your target SharePoint environment may vary from your source environment in its structure and restrictions, it s recommended to identify these variances prior to your migration. Page 2

4 Phase 2: Migration Planning Understand your Source Analyze Plan Model your Target Migrate your content Deploy Each and every migration project vastly differs in its specifications and requirements. It is therefore highly advisable to invest time in planning your migration in order to prepare for these complexities in advance. Most companies start their migration project on a test environment before migrating content to a production environment. Please find our recommendations on planning the stages of your test migration below: Development Phase Migrating 10% of data to a test environment This phase provides the user with a small-scale introduction to the migration workflows, best practices, and the various stages of the migration processes. At the end of the development phase, you should have confirmation that all your migration needs are met by the product. Don t hesitate to contact the Tzunami Support Team to resolve any issues you may encounter with the migration during this phase in order to troubleshoot these issues prior to your actual migration. Migration Proof-of-Concept (POC) Phase Presenting partial results to the client Using either the 10% of migrated data from the Development Phase, or additional data migrated after this phase, make sure that the client is pleased with the migrated results. At the end of this phase, you should have confirmation that all required documents, versions, metadata, security and structure have been migrated according to the client s specifications. Production Phase Apply all previously acquired migration knowledge in order to fully migrate all of the source data to your target SharePoint environment. Please find a list of best practices to guide you through your migration planning phase: Plan SharePoint Hierarchy: Have a general idea which items you plan to deploy as sites, which as lists, and which as documents. You will have a better understanding of your options after starting to work with Tzunami Deployer. Plan metadata migration: Understand which properties of the source system containers you will map to which properties in the SharePoint lists/folders. Know which properties will be added as new properties to the SharePoint lists, Page 3

5 and which properties will be excluded from your project. You can plan your property and user mappings prior to committing your project to SharePoint by creating simple XML files which describe your mappings. Contact Tzunami Support Team for additional information on creating pre-defined mappings. Plan Security Migration: Managing security when you migrate from source security setting to SharePoint is vital. You can plan for deploying security settings (users, groups, and roles) to your SharePoint containers and items.. Maintain source system identity: Always add an identification property from the source system, such as the ID or URL of each item in the source system. Migrating these identification properties in Deployer enables you to easily track the migration of your items after they have been migrated to the target SharePoint. If desired, these properties can be hidden in SharePoint after the migration process has been completed. Pre-Modeling of SharePoint: Model your SharePoint environment as much as you can to suit your migration needs before the migration itself. You can use the Deployer to accomplish this task as well. Plan how you will use your hardware: Multiple Deployer projects may be committed simultaneously in order to speed up the migration commit process. The number of projects you can have running simultaneously on a given computer is dependent on several factors, including: the computer the Deployer instances are running on, the network bandwidth between the Deployer and the SharePoint front-end web servers and the SharePoint farm specifications. Monitor your environment: Inspect system performance (Memory, DB, etc.) while testing the migration with several Deployer instances committing. Three Deployer projects can run simultaneously on a single Dual Xeon Dual-core 2GHz 4GB RAM SAS disk server. Nine Deployer projects can run on a farm consisting of three of these servers. Check migration results in SharePoint: Open SharePoint after committing a test project and make sure all of the data (sites, lists, items, files, metadata, and security) was migrated as expected. Page 4

6 Phase 3: Export, Deploy & Commit Understand your Source Analyze Plan Model your Target Migrate your content Deploy Export Phase Export in small chunks: When exporting from a source system, do the export in small chunks of around 10-25K files each. The chunks should have common business logic. Organize exported data: The exported data should be saved to a folder with a descriptive name and under a well-organized file system hierarchy. It is recommended to export to a folder that is as close to the root as possible. Planning export: Simply exporting ECM content without proper strategic planning can lead you to non-realization of business benefits that your clients had originally perceived. You can plan for content migration as an early up-front activity in the project lifecycle. It reduces total time and cost of exporting ECM contents through Tzunami Deployer Exporter and ECM migration methodology. Move through the migration phases dynamically: It is not necessary to perform the entire export phase all at once. To maximize your time, it is recommended to move onto the next stages of migration after you have completed several exports, while simultaneously continuing to extract more data from your source. This creates a dynamic and time efficient migration cycle of: Export Model Deploy Commit Ensure consistency: Make sure that the different exports do not overlap so that items are not extracted multiple times. It is also important not to make any changes to the source data while performing the export. Monitor your ECM environment: Inspect system performance (Memory, DB, etc.) while testing the exporting content. Don t run more than three exporters instances per ECM front end server (assuming 4GB RAM, 2 GHz Xeon processor server configuration). Monitor server load during export to increase/decrease instances. Batch Export: Use batch export for better performance and scheduling. Validate the exported contents: Review the ECM content reports. Make sure all contents were exported as expected by generating spreadsheets of the export reports and compare with content repository. Page 5

7 Deployer Project Preparation (Content Loading) Phase Use a template project: Create one project as a template (preferably with the SharePoint target loaded into the project). Clone this project using the Save As option from the menu, and reuse the project many times in accordance to the data exported from the export phase. When loading the SharePoint target to a template project, it is recommended not to load the entire farm. In order to avoid wasting time loading data that you will not use for your project, it is advisable to load only the destination top site collection without lists or subsites. All sub sites and lists that you neglected to initially load will appear grayed out in the target, but you will have the option of reloading them later. Be organized: Make sure the project files are saved under a well-organized file system hierarchy. Prepare a project for Deployment (Content Loading) Open one of the projects you have created. Load the source data into the project. Load the structure and then reload desired content within it. Reload the target destination site/sub-site/list which is probably not fully loaded (if you followed the instructions in the previous phase). If you are migrating documents to a target list which already contains many documents, it may be unnecessary to load all the existing documents when reloading the list. However, choosing not to load all of these documents could inhibit Deployer from identifying duplicate file names. Document versions for target need not be loaded. Work on multiple projects in parallel. You can run 3 instances of Deployer on one front end server (assuming 4GB RAM, 2 GHz Xeon processor server configuration). However it is recommended that the instances be increased or decreased based on server load. Deploy Phase Drag and drop: Deploy selected items from the source to a pre-determined location in the target. At this stage of the Deployment, you should already be aware of what you re dragging (site, list, etc.) and which properties you want to add accordingly. Mass Deploy: Repeat the Drag and Drop phase for as many projects as you like. Keep in mind that using more than one person to conduct the migration Page 6

8 can help you move through the different phases simultaneously and thereby at a quicker pace. Make sure not to deploy the same site collection using two different projects that are destined to run simultaneously, as this could cause inconsistency issues. Review the Deploy Reports for any warnings Check for problems before commit: Before committing your project to SharePoint, use the find problems option from the Deployer menu (Ctrl +P) in order to identify any issues that may occur as a result of SharePoint limitations, such as long URLs, or blocked extensions. SharePoint Limitations: Keep in mind SharePoint column limitations while adding missing properties. Multiple Deployment: Simulate multiple deployments for a source type till you find the one that suits your needs best. Use the same deployment pattern for that item type in future. Commit Phase Check for problems before commit Start committing the projects: While these projects are committing, begin creating as many new Deployer projects as you can. Run several Deployer instances on one server: The number of Deployer projects running simultaneously on one machine and the total number of projects which can run simultaneously depend on your hardware, network connection and SharePoint environment maintenance and response time (free memory on the machines running Deployer, HD availability, CPU, network connectivity to the SharePoint farm, DB indices on the SharePoint SQL server, etc.). Don t waste time: You can immediately commit another project as soon as the previous project finishes committing. You also have the option to schedule a commit in the future through the use of the Microsoft Windows Task Scheduler combined with Deployer s command line capabilities. Keep in mind SharePoint column limitations while adding missing properties. Avoid performing changes to the SharePoint outside of Deployer during the commit phase. In order to produce a rough estimation on the duration of the Commit Phase, verify the following environment-dependent variables: X: Total number of documents to commit Page 7

9 Y: Average commit rate for one Deployer instance. Test this once with one project committing M documents for H hours and just do a simple calculation of M/H. Z: Number of servers available to run Deployer N: Number of Deployer instances designated to run on each server. Note: It is not recommended to run more than 3 Deployer instances on a single server. Rough time estimation for the duration of the commit process can be calculating using these parameters: (X*Y)/(N*Z) Schedule Commit: With Scheduled Tasks, you can schedule Tzunami Deployer to commit a project at a time that is most convenient for you. Identify Issues: During commit, or any other phase of the migration project, identify any problems that may arise. Save the export/deploy/commit reports and logs which contain any warnings or errors. Notify the Tzunami Support Team about these issues. Final Phase Validate the migrated data after committing: Review sites/lists/folders/items in your SharePoint. Make sure all data was migrated as expected (including metadata, attachments, security configurations, etc.). Save the project files, logs, reports and exported data: These files can be useful for a multitude of scenarios, and it is therefore advisable to save them until you finish your project. Page 8

10 Annex BEA AquaLogic to SharePoint ECM Documentum to SharePoint Xerox DocuShare to SharePoint ECM Documentum eroom to SharePoint Exchange to SharePoint Hummingbird DM to SharePoint LiveLink to SharePoint LotusNotes to SharePoint BEA AquaLogic to SharePoint Migrate folders to their relative list types, based on the items in those folders: Table 1: Best Matching for AquaLogic to SharePoint AquaLogic Item Type Projects/My Projects/Archived Projects Project Documents Content Service Windows Files Task List Announcements Calendars Discussions Knowledge Folders Knowledge Documents Knowledge Links Relevant SharePoint Types Site Collection Site Documents inside Libraries Document Libraries Tasks List Folders inside Tasks Lists Announcements List Calendar List Discussion Board Document Library Folders inside Document Libraries Documents inside a Document Library Link inside a Links List. Documents inside Document Libraries (with the Link to a Document Content Type) Knowledge Links can be migrated in two ways: Migration as data-items in a Links List. Page i

11 Migration as documents in a Document Library. MOSS/WSS3.0 provides a Content Type named Link to a Document, which functions in a similar way to a shortcut. For more information about migrating using this Content Type, please contact the Tzunami Support Team, at support@tzunami.com. ECM Documentum to SharePoint Follow the guidelines below when choosing the target structure. Table 2: Best Matching for Documentum to SharePoint Documentum Item Type Cabinets Folders Documents Virtual Documents Relevant SharePoint Types Site/Site Collection Document Library Folder/Document Library Document Folder Document Library Xerox DocuShare to SharePoint Follow the guidelines below when choosing the target structure. Table 3: Best Matching for Xerox DocuShare to SharePoint DocuShare Item Type Workspaces Collection Calendar Events Bulletin Boards, Topics and Replies Weblogs and Weblog Entries Documents URLs Mail Messages Relevant SharePoint Types Web Application (create manually in SharePoint). Site Collection Site Collection/Site Document Library Calendar Calendar Items Discussion Discussion Messages Post Comments Document Library Data Items Document Library(MSG files) Page ii

12 DocuShare Item Type Relevant SharePoint Types Generic (Custom) List (data-items with attachments). ECM Documentum eroom to SharePoint Follow the guidelines below when choosing the target structure. Table 4: Best Matching for eroom to SharePoint eroom Item Type Facilities Room Discussion Poll Calendar Project Plan Inbox Database Folders Documents Notes Links Relevant SharePoint Types Web Application (create manually in SharePoint) Site Collection Site Collection Site Discussion Board Survey Calendar List Task List Gantt Custom List For the basic database templates, some SharePoint lists (Contacts List, Links List, and so on). Generic List Depending on the content of the folder, valid options may include migrating as Lists, Folders, or even Sites. Files in a Document Library Items in a Generic List Items in a Links List When migrating Polls as Surveys, each question is represented as a property. You can add the various questions as part of the deployment process. For more information about adding properties and using the Rule Engine, refer to the Tzunami Deployer Users Guide. Top-level folders should be deployed as Sites and Sub-sites, in order to better organize the content in a SharePoint-oriented structure. The items of these folders can be divided between the lists in the sites. For folders that contain several types of items, Tzunami recommends filtering the folders based on the eroom Item Type property and migrating each type Page iii

13 of item to a different list. For more information about filters, refer to the Tzunami Deployer Users Guide. Exchange to SharePoint Migrate folders to their relative list types, based on the items in those folders. Table 5: Best Matching for Exchange Server to SharePoint Exchange Folder Containing Mails Contacts Calendar Tasks Notes Documents RSS items Relevant SharePoint List Types Document Library (MSG files) Generic (Custom) List (data-items with attachments) Contacts List Calendar List Tasks List Generic (Custom) List Document/Picture Library Document Library Generic (Custom) List (data-items with attachments) Profile properties/columns can be added to the items as part of the deployment. For more information about adding attributes, refer to the Tzunami Deployer User Guide. Mail items can be migrated as MSG files into a Documents Library. Microsoft Office Outlook or similar software is required to open these documents. Data-items in a Generic List. The attachments of the mail item become attachments of the data-item. The body of the mail is migrated as a property of the items. Note that some reformatting may occur due to SharePoint limitations. Note that, embedded images and drawings are not migrated. RSS items can be migrated as MSG/MHTML files in Document Library. Supported software if required to open these documents. In this case, the Full Article attachment of the RSS items will not be migrated. Data-items in a Generic List. The Full Article of the RSS item becomes the attachment of the data-item. It is often useful to add properties that exist for items in Exchange (but are not part of the default lists in SharePoint) to ease working with the content. For example, when migrating mail items, it might be useful to add TO, FROM, and Page iv

14 RECEIVED properties to the list. This enables users to sort, group, and filter the items based on these columns. The Tzunami Deployer Rule Engine provides a similar default behavior, out-of-the-box. For more information about adding properties or using the Rule Engine, refer to the Tzunami Deployer User Guide. Hummingbird DM to SharePoint Migrate folders to their relative list types, based on the items in those folders. Table 6: Best Matching for Hummingbird DM to SharePoint Hummingbird DM Item Type Workspace, Library, Search Folder Public Folder Document Relevant SharePoint Types Site Collection Site Site Collection Site Document Library Folder inside a Document Library Document inside a Document Library Profile properties/columns can be added to the items as part of the deployment. For more information about adding attributes, refer to the Tzunami Deployer User Guide. Top-level folders should be deployed as sites and sub-sites, in order to better organize the content in a SharePoint-oriented structure. LiveLink to SharePoint Migrate folders to their relative list types, based on the items in those folders. Table 7: Best Matching for LiveLink to SharePoint LiveLink Item Type Workspace Channel Discussion Project Task List Task Group Relevant SharePoint Types Site Collection Site Announcements List Discussion Board Site Collection Site Tasks List Folder inside a Tasks List Page v

15 LiveLink Item Type Compound Document URL Alias Document Text Document Folders Relevant SharePoint Types Folder Link inside a Links List Document inside a Document Library (with the Link to a Document Content Type) Link inside a Links List Document inside a Document Library (with the Link to a Document Content Type) Document inside a Document Library Document inside a Document Library Depending on the content of the folder, valid options may include migrating as Lists, Folders, or even Sites URLs and Aliases can be migrated in two ways: Migration as data-items in a Links List. Migration as documents in a Document Library. SPS2010/SPF2010 or MOSS/WSS3.0 provides a Content Type named Link to a Document, which functions in a similar way to a shortcut. For more information about migrating using this Content Type, please contact the Tzunami Support Team, at support@tzunami.com. Attributes (derived from Categories or from Additional Node Attributes) can be added to the items as part of the deployment. Note that in LiveLink, each item can be assigned several categories while in SPS2010/SPF2010 or MOSS/WSS3.0 each item can only have one Content Type. For more information about adding attributes, refer to the Tzunami Deployer User Guide. Top-level folders should be deployed as Sites and Sub-sites, in order to better organize the content in a SharePoint-oriented structure. LotusNotes to SharePoint Extract Lotus Notes content based on source template. If your database is not generated from one of the standard templates, or if you are not sure about the database template that you are extracting, carefully analyze the contents and decide the export type based on the equivalent list/library available in SharePoint. The exporter will make some automatic suggestions to help you choose the export type if the database template is known. Here are some suggestions: Page vi

16 Table 8: Best Matching for Lotus Notes to SharePoint Lotus Notes Item Type Document Libraries Calendars Mails To Do Lists Address Book Discussions Relevant SharePoint Types Extract as Documents OR InfoPath Document Extract as Data Items OR InfoPath Document Extract as Data Items Extract as Data Items Extract as Data Items Extract as Data Items These are just some suggestion based on the nature of the template. You may still want to analyze the database and consult a SharePoint expert to decide which export options would be best for you. You may also try exporting contents under different options till you know what is best for your scenario. It is recommended that you close the Lotus Notes application prior to starting the export. Lotus Notes imposes some limitation on the number of resource instances (in-memory segments, handles etc.) that can be allocated at a time. This may affect your export especially if you are doing bulk export which might require high resources. Closing Lotus Notes applications during export will make all resources available to the exporter, thus reducing the chances of export failures. As much as possible do not run other applications on the exporter machine while the export is in progress. Make sure that you are logged into the machine with admin rights where you are running the export for the first time. The exporter may need to register some environment variable(s) to configure the export environment. This will need admin access. Once these settings are done one a machine, a user with non-administrative rights can also use the exporter. If you are connecting the Lotus Domino Server via Lotus Client, during export of huge database from a Domino Server, it is recommended to run the exporter in a machine where the Lotus Domino Server is installed so that exporter can select the database locally. The reason to do so is generally it takes much longer time to extract large size database from the Server (Network). While exporting: 1. Export in small chunks: When exporting from your source system, perform the export in small chunks of about 40K-50K files each that have a common business logic or some other logic. 2. Ensure consistency: Make sure that the content of the different exports do not overlap and that, while exporting, no changes are made to the source data. Page vii

17 When extracting as document it is recommended that you choose to extract as DOCX (in the advanced settings) if there is no strict need to extract in DOC format. This will speed up the export process and reduce resource consumption during export. It is recommended that you select Extract documents with no form checkbox. In Lotus Notes, there are some documents that don t have an associated form. One such example is Notes mail messages. If you do not check this option, these documents will not be extracted. Note that documents without a form will be extracted as data items. This may create documents as well as data items in the same folder. You should deploy the two types of items into separate lists in SharePoint. Make sure that you have enough disk space in the System drive of the machine where you are running the exporter. The free disk space should be at least two to three times the size of the database that you are exporting. While exporting views as folders, it is highly recommended that you choose specific folders rather than selecting the root folder and exporting the entire hierarchy. Carefully choose the specific folders to export will significantly reduce export time and prevent item duplicity in different folders. When extracting as document it is recommended not to select Save attachments as separate files if there is a close relation between the parent document and its attachments. If however the parent document is just acting as a container for different objects and files you may want to use this option. Please be aware of the fact that extracting attachments as separate files will effectively break their relationship with the parent document. Do a small test migration first. Before you start large scale migration, perform a small migration to a test site and make sure that you understand how the Deployer and the Lotus Notes Exporter function; how data is mapped from the source to the destination items and which migration option suit you best. You can refer to details about Deployer features in the Tzunami Deployer User Guide. If a rendering form is not found for a document, it will be extracted as a data item, even if you opted to extract as document. This may create two types of item in the same exported folder. In such cases Tzunami recommends the migration of each type of item to a different list since documents and data items cannot be deployed to a single list in SharePoint. Some Lotus Notes content will map to standard SharePoint templates such as Document Library, Calendars, Discussions and Tasks. Others will require customized template selection to accommodate additional data columns or content types that are not standard in SharePoint. Page viii

18 Considering the SharePoint limitation for custom roles, the Exporter will extract Lotus Notes custom roles as Groups. Any Access Control List in Notes content must be mapped to permissions in the corresponding SharePoint sites, lists, libraries, and even individual data documents during deployment. While deploying as InfoPath: 1. Not selecting Extract views as folders option: if you are exporting Notes documents as InfoPath without selecting the option Extract views as folders, it is not recommended to deploy the top level folder with database (NSF) name as root site in the target SharePoint for full browser support. 2. Selecting Extract views as folders option: If you are exporting Notes documents as InfoPath with Extract views as folders option selected, it is not recommended to deploy folders with view name (under the folder with database name) as root site in the target SharePoint for best turnout. Figure 1: InfoPath Deployment (with extract views as folders option selected) Page ix