Portfolio

SharePoint 2010 to Office 365 migration

Agriculture body gains more value from its intranet through Office 365 migration

egforit Software helped this agricultural board modernise its staff intranet via SharePoint 2010 to Office 365 migration.

Executive brief

Agricultural intranet modernisation

Our client is a statutory board representing over 70 percent of the Egypt , middle east agriculture sector. egforit Software carried out a SharePoint 2010 to Office 365 migration of the board’s staff intranet. The key outcomes of this SharePoint content migration were:

no more upgrades required

reduced IT expenditure

intranet access everywhere

full staff intranet adoption

Wondering how the board achieved this through SharePoint content migration? Read on to learn more.

The full story

Purple arrow encouraging readers to scroll down for the rest of the insurance intranet development case study

The challenge

SharePoint upgrade was overdue

At the time of this project, the agricultural board was using a SharePoint 2010 intranet, hosted on-premises. But with SharePoint 2010 end of life looming, the board saw it was time for a SharePoint migration.

 

Around half of the board’s 400 staff used the SharePoint 2010 system. The intranet’s main functions were central document management and project management. Overall, the intranet contained around 160GB of content in 11 site collections. This content included custom SharePoint Content Types and SharePoint Web Parts.

 

Rather than stay on-premises, the board decided to migrate SharePoint 2010 to Office 365, in the cloud. But without in-house knowledge, the board needed a team of SharePoint experts to make the migration a success.

The solution

SharePoint 2010 to Office 365 migration

Phase one: SharePoint audit

The complexity of the board’s intranet content required a phased approach. In the first phase, we carried out a full intranet inventory and audit. The use of automated tools and PowerShell scripts helped us rapidly analyse the intranet and produce a report detailing:

 

  • custom solutions
  • workflows
  • content types
  • site columns
  • permissions
  • user alerts
  • users and groups
  • large lists or libraries
  • UI customisations
  • organisational branding

 

With this understanding of the existing system, we were able to successfully plan the upcoming SharePoint content migration.

Phase two: SharePoint preparation

In the second phase we cleaned up the content to be migrated and prepared the new Office 365 intranet. This process consisted of:

 

  • finding and removing “orphaned users”
  • removing empty SharePoint Groups
  • putting users with explicit permissions back into Groups
  • deleting unused content types, site columns, and workflows
  • identifying sites that were no longer needed
  • finding large site collections for break-up into smaller ones
  • removing unwanted versions from version history
  • reorganising lists and libraries with too many columns
  • rethinking and reorganising very large lists

 

This clean-up ensured the new intranet would be well-structured from day one.

Phase three: SharePoint content migration

In the final phase, our engineers built a cloud-based SharePoint system with the agricultural board’s fonts, logo, and colour scheme.

 

Once the new system was set up and configured correctly, it was time for the SharePoint 2010 to Office 365 migration. We achieved this with Metalogix Content Matrix, a powerful SharePoint content migration tool. This software enabled us to achieve a faster, less risky, and more transparent migration.

The benefits

Future-proof intranet achieved

The key benefit of this SharePoint on-premise to Office 365 migration was the freedom from further upgrades. Based in the cloud, SharePoint Online is entirely maintained and updated by Microsoft. This supported the agricultural board’s goals of cutting IT costs and providing better value for its stakeholders.

 

In summary, the organisational outcomes of this migration were:

 

  • no more costly maintenance of on-premises SharePoint servers
  • the flexibility to adopt a hybrid strategy for organisational data
  • a streamlined intranet with unused content and users removed
  • higher staff adoption thanks to accessibility on all devices, everywhere

Choose Office 365 migration specialists

From agricultural software to online banking, from climate reporting to logistics platforms, we serve every sector. Find out more on our portals page.

Info

5th January 2021
migration, upgrade, SharePoint, Office 365, intranet

Privacy Preference Center

Necessary

Advertising

Analytics

Analytics cookies collect information that is used either in aggregate form to help us understand how our Websites are being used or how effective our marketing campaigns are, or to help us customise our Websites for you.

Google Analytics
The cookie _gcl_au is used by Google Analytics to understand user interaction with the website.

For example, in order for Google Analytics to determine that two distinct hits belong to the same user, a unique identifier, associated with that particular user, must be sent with each hit.

The analytics.js library accomplishes this via the Client ID field, a unique, randomly generated string that gets stored in the browsers cookies, so subsequent visits to the same site can be associated with the same user.

By default, analytics.js uses a single, first-party cookie named _ga to store the Client ID, but the cookie's name, domain, and expiration time can all be customized. Other cookies created by analytics.js include _gid, AMP_TOKEN and _gac_. These cookies store other randomly generated ids and campaign information about the user.

Google Analytics
_gcl_au, _gid, _ga, gtm_preview

Other

WordPress uses cookies for authentication. That means that in order to log in to our WordPress site, you must have cookies enabled in your browser.

There are two types of cookies set by WordPress.
1 — Session cookies — These are ‘strictly necessary’ cookies as WordPress will not be able to function without it.
2 — Comment cookies — These are not ‘strictly necessary’ cookies and are set when users leave a comment on a post.

Wordpress Session cookies:
Users are those people who have registered an account with the WordPress site.
wordpress_[hash]
wordpress_logged_in_[hash]
wordpress_test_cookie
wp-settings-{time}-[UID]

Wordpress comments:
Comments are usually turned off by default.
If by chance they are still active on a post, asides being turned off when spotted, data from these are not saved by egforit.
- When visitors comment on a post, they too get cookies stored on their computer. This is purely a convenience so that the visitor won’t need to re-type all their information again when they want to leave another comment. Three cookies are set for commenters:
comment_author_{HASH}
comment_author_email_{HASH}
comment_author_url_{HASH}

Wordpress,
comment_author_{HASH} comment_author_email_{HASH} comment_author_url_{HASH} wordpress_[hash] wordpress_logged_in_[hash] wordpress_test_cookie wp-settings-{time}-[UID]
-id-[app_id],-session-[add-id]

×