| ITIL : 41 Support
03 Data Migration Methodology | |
|---|
| 1. Data Migration Methodology | | 1. To undertake each data migration project using professional methods that have been proven to be complete and correct - subject to Non-Disclosure Agreement. | | 2. To continually improve the data migration methodology with the benefit of hindsight from each project so the level of automation increases and the cost decreases. | | 3. To always adopt the following nine step methodology, even where some steps may be trivial as: | | (1) Portfolio Analysis: to plan the plan by evaluating exactly what has to be migrated. | | (2) Governance: to plan retentions, permissions, user access and rights. | | (3) Communications: to establish a two-way communication channel with all stakeholders - email may be good enough. | | (4) Architecture: to define the hardware and software needed to complete the project. | | (5) Customization: to filter out what cannot be migrated and to extract what can be migrated. | | (6) Migration Run: to eliminate decision points and just run the scripts. | | (7) Known Error Database: to accpt that migrations are never complete and that errors are expected. | | (8) Disruption: to mitigate disruption while data is being migrated. | | (9) Adoption: to advise approved people how and where to find their data. | | 4. To assume that planning the plan as step one is a self contained project in its own right to document the scope of the migration as a second project. |
| 2. Source | | 1. To define the source of the data as one and only one logical source place. To plan for each different type of data source to be a different project. | | 2. To define governance as what data is to be migrated and to define what access rights are applicable. | | 3. To filter out that data that is obsolete and system data that should never have been stored. | | 4. To classify existing data as: | | (1) Active: documents that have a known purpose and may be used in the future. | | (2) Archive: files that have no known purpose and may never be used in the future. |
| 2.2. Active Documents | | 1. To identify that "active" documents are those files that can be processed by Office 365 tools with a file type as: | | (1) Word: as DOC, DOCX, RFT and TXT files. | | (2) Excel: as XLS, XLSX, XLT and CSV files. | | (3) PowerPoint: as PPT, PPTX and ODP files. | | (4) Edge: as PDF, HTM, HTML, PNG, JPG, JPEG and GIF files. | | (5) Outlook: as MSG files. | | (6) Access: as MDB files. | | 2. To understand that the only documents that have any value to the organization in the future are those that can be processed using Office 365 tools and that all other files types have become obsolete and unusable. |
| 3. Target | | 1. To define the target destination of the data to be one and only one logical storage place. To plan for each different type of data target to be a different project. | | 2. To define governance as what data is to be stored and what access rights are to be applied. | | 3. To filter out that data that cannot be processed in the target environment. |
| 3.2. Archive Documents | | 1. To identify that "archive" files include all kinds of system files and obsolete program files that no longer can be used. | | 2. To skip cookies, links, recent file database, favourites, recycle bin contents, private pictures, private music, browser history, media player, application data, downloaded programs, temporary files, updates, my scans, daddress book, contacts, printer drivers and personal messages. | | 3. To skip empty files, empty folders and files without any file type. | | 4. To skip files that cannot be accessed because of unknown permissions, unknown passwords or where ownership of the data cannot be verified. | | 5. To skip installation files, executable files and start menu program links. | | 6. To skip backup dumps of smart phone contents and emails that cannot be processed in the future. | | 7. To exclude data with a file type as: | | (1) Executable: as EXE, COM, DLL. | | (2) Endora Phone: as MBX, CLX, TLX, ISU, HLP, PCE, GID, INI, CNT. | | (3) Phone Backup: as WBK, LOG, DAT, LIN, NAV, MOD. | | (4) Email: as PST, TOC, ESD. | | (5) Old Apps: as WP4, WB3, CDR, SDR, MPP, QPW, ENL, JNB, JBF. | | (6) Remote: as RDP, UPL, BU!, DOW, POW. | | (7) all cookies and browser history as files without a file type. | | 4. To exclude folders that do not contain actice documents as: | | App Data, Application Data, Contacts, Desktop, Desktops, Downloads, Email Attach, Favourites, Identities, Links. | | My Music, My Pictures, My Videos, My Scans, Plugins, Recycle Bin, Scripts, Stationery, Saved Games, Searches, Start menu. |
| 4. Known Error Database | | 1. To accept that empty folders should not be migrated. | | 2. To accept that empty files should not be migrated. | | 3. To accept that temporary files should not be migrated. | | 4. To accept that system files should not be migrated. | | 5. To accept that files that are locked and unreadable cannot be migrated. |
| 5. Disruption | | 1. To minimise the duration that data is not available by utilizing night time and week end working. | | 2. To run the first migration run while existing data is still available to be changed and then run a seond migration just to catch up with the data that has been changed since the first migration. | | 3. To plan that where the amount of data to be migrated is very large, then several migration jobs may be applicable with each job getting faster and faster as the amount of data that has changed since the last migration gets reduced. |
| 6. Education | | 1. To understand that the primary role of the support team is education - to provide enough education until support is not needed. | | 2. To treat the gathering of issues and publication of proven solutions as educational - to use YouTube videos when applicable. | | 3. To understand that migration is only complete and correct when all approved people are comfortable using the new target data storage place - the project does not end when the data is migrated at step 6. | | 4. To promote the information privacy policy based on: | | (1) Personally Identifiable Information (PII) that is defined by GDPR laws where people own their own data that is loaned to the organization with consent until that consent is withdrawn or after the information has not been processed for seven years. All human resource and payroll information is PII that must be encrypted and replicated to eliminate the threat of a reportable data breach. All personal emails are PII that must never be disclosed to any other person than the person named as the recipiant. | | (2) Legal Information is any information that is or may be the subject of legal procedings including complaints that are goverened by legal council who will distate what may be disclosed before the information is physically destroyed after ten years. | | (3) Private Business Information is any internal information that cannot be disclosed because it is the subject of a NDA or if disclosed would provide an unfare advantage to a competitor such as financial transactions, HR activies and operational activities that do not need to be made public until is is destroyed after seven years. Opinion is that much of the business informtation that was classified as private could and should be classified as public - public is the default where private was the default. | | (4) Public Information is everything else that may be disclosed in an open honest and transparent way, but not all public information will be worthy to be published. |
| 7. Risk Assessment | | 1. To begin planning the plan with a risk assessment so all eventuallities are documented. | | 2. To accept that the duration of a migration project is not easy to preduct because some external factors such as network utilization is not measurable. | | 3. To accept that every migration project has errors where some data is unreadable, has a names that is too long, has hidden symbols in the name and a large number of issues that are expected, but the scope cannot be predicted. | | 4. To mitigate risk by increasing the time line to handle all eventualities that are planned and unplanned. | | 5. To mitigate risk by designing a plan where migration can be repeated over and over again until a satisfactory result is obtained. | | 6. To mitigate risk by designing a fallback plan in the event that the migration architecture is not able to achieve what was expected of it. | | 7. To understand that every migration project fails to deliver a 100% complete and correct result - so manage expectations and manage the errors that will be identified. |
| 8 Ownership | | 1. To manage continual ownership of all data to be with the customer and never with the party undertaking the migration - that can become critical. | | 2. To understand that when the new storage system is established in the cloud, the ownership of that cloud must be with the customer and the customer must have rights to prevent the migration party from accessing the data. | | 3. To accept that migration is done for the customer and when it is completed, ownership of the resulting storage system is with the customer. | | 4. Too many times when a public web site is created for a customer, the customer does not own that web site and is locked in to pay for maintenance - the same lockin can happen with storeage systems. |
| Document Control: | | 1. Document Title: Data Migration Methodology. | | 2. Reference: 164103. | | 3. Description: Data Migration Methodology. | | 4. Keywords: Data Migration Methodology. | | 5. Privacy: Public education service as a benefit to humanity. | | 6. Issued: 13 Feb 2019. | | 7. Edition: 213. |
| SharePoint Migration Tool |
|
|