top of page

DISCUSSION: LEGACY SYSTEM CONTENT MIGRATION

Author: Jonathan Stuckey


Legacy repositories and file-shares

Platform and data-migrations are not new. The issues are very well defined and understood ...so why does it always feel like a you are climbing a mountain without the right equipment or a guide?


Partly it's because a getting business case and investment in moving content around is just hard - its 'cleaning-up' and no one wants to do that. Partly it's because it is seen as unproductive, and the project is not moving the organisation forward.

physical metaphor of file-server clutter
It's in here... somewhere?!

It is far easier to get investment for Sexy (stuff that gets talked-about) or Shiny (new or modern) projects.


Cleaning-up feels like being a teenager with your parents asking you to sort your bedroom out.


Why move to a new store

Decision criteria for reviewing legacy repositories and / or migrating content between platforms is typically based on a combination of one or more of the following

Operational costs
  • License costs escalating for software or a services - vendor increasing costs

  • Service management cost is escalating with no discernible value or improvement


Support
  • Declining or no vendor support in market

  • No skills or people available - internal support becoming too costly, or not available


Risk / Issue management
  • Response to an incident - i.e. privacy breach, security breach, data-loss issues, or litigation

  • Dependency on aging | unsupported | unmanageable platform - high-risk of incident eventuating

These are all the 'stick'. There's virtually no 'carrot' in these scenarios, because its about managing negative impacts. Benefits (the 'carrots') are often poorly presented and taken as a low value returns by business owners and managers alike.


Value is usually presented in vague arm-wavy terms for end-users like 'save the equivalent of a cup-of-coffee per day' without defined tangible outcome or bottom-line ($) impact. E.g.


Improved productivity

  • Improve findability (made-up word) - easier to find authoritative, accurate and current items

  • Reduce effort from recreating content - users avoid repeat activities on the same task

What value can you gain by migrating

Because legacy platforms like file-shares are basic in their investment in underlying information management tooling, and were extremely cheap to deploy and use, they became a ubiquitous commodity for many different solutions. See the article on Migration.


Classic benefit and value statements or objectives are around:


  1. reduce escalating costs of legacy (aging) infrastructure

  2. avoid escalating costs of support for platform

  3. reduce risk of critical incident occurrence - and subsequent response

  4. reduce overhead of responding to regulatory, or legislative action (including legal discovery)

  5. enable easier access and usability of historical content - by moving to somewhere indexed and managed


With commoditisation of advanced technologies in Artificial Intelligence (AI), Machine Learning (ML) / Deep Learning, Automation and Robotics, migration project benefits and value statements can now include things like:

  1. enable opportunity for mining and (re)use of historic data - leverage AI and ML over your content

  2. reduce effort of process-management and analysis activities - with automation using Bots, AI

  3. decrease time and effort in (re)use business IP - with AI, ML and Large-language models (LLMs)


Modern benefits haven't so much had an evolution as had a Revolution since 2022. Content migration from legacy systems and file-shares just got 'Sexy'!


Where's the actual effort

Unfortunately, that means you need to treat a legacy repository migration (even file-server migrations) like proper project, because the Sexy outcome is not acquired by magic. To prove the point, in order to use things like AI, Bots, ML and Automation there has to be investment in your data-management and Governance.


The majority of effort in content migration is actually in the wrap-around to the project and the change management.


1.      Pre-migration it's all about understanding what you have, where you are likely to get issues in migration:

i. data integrity

ii. system integrity

iii. access and security mapping

2.      Planning migration strategies and investing in the right type of tooling to support minimising manual intervention of clean-up or change during migration.


3.      Content Migration - perceived as the 'easy' bit, which stakeholders believe is the only bit in the project, which is always more than copy-n-paste from a file-server to a library.


4.      Reporting and reconciliation once content is moved, and accounting for errors, corruption, missing data and mistakes in transcription or mapping.


5.      Switching over from old to new, including remembering to disable the access to the old environment to step off into the new environment - otherwise you have only exacerbated the original issue(s). ...and create a plan for decommissioning.


6.      User enablement (change management) - ensuring that users are facilitated in accessing the new environment; prevented from accessing the old environment; have support for questions or issues; can talk to a person for any escalations, and are involved in approving sign-off.


...and you know what I have not included above? Governance. Governance of the content now in the new environment; management of the platform and service configuration and options; ongoing user support or ensuring appropriate training to ensure future consistent usefulness of content.


What are the common risks and issues

There are lots of risks and issues in migrations and strangely enough file-server migrations can be subject to all of them, even ones we normally anticipate from migrating from more sophisticated ECM platforms. The most prevalent though are:


  • Perception of stakeholders and executives

    • failure by the sponsors and stakeholders to understand the benefits realisation has to be earned by the work required before & after the move, it is not gifted by an IT tool

  • Poorly defined or made-up use-cases for migration e.g. the magic of AI

    • Cost savings have to be big and easily identified, but are not enough on their own (unless about to dramatically increase);

    • Risk management and regulatory obligations are perceived as low-value return and therefore come with a low investment ceiling before being stopped;

    • Supportability is viable driver when coupled with other items e.g. cost-savings, regulatory obligations etc, but really need to map TCO model to prove the need to move - file-servers are proven as the lowest (perceived) tco and supportability requirement and this will not provide enough of a drive without other factors to support the move

    • Privacy/Security breaches are reactive cases and only provide a 3 - 6 month window before something else take the executive's attention

    • Business enablement - Microsoft, Google, OpenAI and others do not fully understand the value of these tools for you.

      • Suggested use-cases are speculative and should be examined in lab for your organisation

      • Your use-cases have to be developed by enabling your best and brightest with the tools and access to the content.

      • investment in the enablement will be post migration - this is speculative and tenuous for business owner without vision

  • Understanding what you need to do to actually migrate

  • Source content quality

    • whether on file-server or EDRM platform analysis and clean-up of file-path lengths (folder-depth), file-name lengths and unusable characters, zero-byte files, soft-links etc is minimum starting point for migration to SharePoint

    • understanding the mess that will be the applied access model, security groups (nested, orphaned, unused) and permissions - is critical when determining the model applied in the new environment


The fall-back option

In the event that you cannot take the stakeholders on a journey of understanding, and the fallacy of "file-server equals 'simplicity' for migration" you can always fall back on the tried and tested method of 'cut-n-paste' of content. IT have been doing this for years. It doesn't deliver any value, it does not enable any usable outcomes, and it barely delivers any cost-savings - but hey, at least the sponsor can claim they 'streamlined' things in the project.


Some observations with 'fall-back' options seen in many migrations:


  1. The project runs out of money and resources. Usually because of unrealistic initial estimates and lack of understanding of what actually needs to be done. Typical results:

    1. the project is de-railed and mothballed (again). Result - no content migrated, no accessibility improvement, no improvement for users access content, increased storage costs, maintains data access and sharing issues and privacy risks... Ignores the issue: making it "somebody else's problem", or

    2. project does not complete e.g. the legacy platform or file-server is not removed. With this outcome the best you get is the content is relocated to a newer version of file-share solution like Azure file-services etc. It is a net-neutral, sideways move. Lot of money is spent with no tangible outcome or benefit. Project justifies a negative perception for moving.

    3. content is duplicated into 365 with clean-up of old platform. The content is replicated but original not restricted or decommissioned. Net result - doubling the problem. Now you have two systems, twice the content, neither authoritative, multiple access models. Project exacerbates existing problems

  2. The project closes-out in a rush without delivering value. i.e. content is moved but is now less usable than before. Importing without clean-up, remediation and applying governance gives increased risk of privacy breach and security / access issues; Minor improvement from search results if people know how to drive tools, but you can disable and remove old file-server/solution. Project has minor benefits, but amplifies existing usability issues and risks

None of the above enable the organisation to benefit from new technologies and enhancements from AI.


Assessment

If you have been struggling with getting your organisation behind a migration from legacy EDRM or file-shares, take a look at what Generative AI can do for your approach, investment planning and business case. The answers and supporting content generated from various services, provide between 30 - 40% of what you want and reduced the time in generating the business case by ~50% over prior experiences.


You can present good reasons for investing the time and effort, but you cannot make your content magically useful without actual work.


Caution:
Generative AI is not going to write your case, because while it can provide a raft of useful (and some laughable) reasons to approach legacy migration, the biggest benefits for your organisation are always specific to your situation.

Secondly AI and ML are not going to remove the actual migration effort, but it will shift your project focus from basic technical tasks to getting better usability of the content post-move - if you do not let the business rob you of the funding.


Organisations who see these tools as an opportunity to only reduce the cost of the physical shift of file-content will fail.


Want to know what we know? Give us a call!

If you want to understand how to get the best from migrating your content from legacy systems to Microsoft 365, give us a call: hi@timewespoke.com 


About the author: Jonathan Stuckey


About this article: This article has been composed with support of GenerativeAI tools. The analysis and opinions are the result of the authors' experience.

Commenti


bottom of page