Intranet Migration from SharePoint Portal Server 2001 to Office

SharePoint Server 2007

Background

A short history- Original intranet built in 2002 on Portal Server 2001

- Now becoming unreliable/unstable

- Not recoverable or scalable

- Not a suitable platform for moving forward with business drivers, e.g. Enterprise Content Management, Records Management, Knowledge Management, etc…

- Basically, end of life

New outcomes and approach:- Recoverable and reliable

- Implement a consistent taxonomy (meta-data) across the organisation

- Best practice SharePoint 2007 implementation – architecture and development

- Similar look and feel – don’t scare the users (small steps)

- Build a scalable platform – this means, there’s more to come!

Prerequisites/Strategies for success

Resourcing, and in particular skill levels of that resource

Having the organisation agree on a company wide taxonomy – for our project, the taxonomy was made into a business issue and handled outside of the SharePoint project

Being focussed on the project plan and outcomes – keep eye on any creep

Good project management

Identify key staff in the organisation to be evangelists, work on them

Clear and regular communications done

Don’t swamp users with information, you’ll scare them away (the drip feed approach)

Be realistic with timeframes and what can be achieved and done well

Have a plan for post-project agreed promptly after live

Blackboard (http://blackboard)

Main “home” portal/page

News

Portal links

Includes the IBF and Induction pages (as before)

New speedy phone list (AJAXified!)

Site directory

Blackboard (http://blackboard) cont

Team Sites (http://teams)

Collaboration sites for teams

Custom templates into central document management library

Team Sites (http://teams) cont

Custom searches for certain teams

Documents Portal (http://documents)

Central managed location for all documents

Documents in here are managed, versioned, archived, bar coded, …

Careful taxonomy set (content types) applied to each library based on different types of team (e.g. Legal has > 10 content types!)

Overview: Documents and the IBF

The IBF has been used to define a taxonomy of Content Types – distinct sets of meta-data/columns required for different types of document (functional, not file type)

Content Types are organised into a hierarchy – so a column at the “Controlled Business Document” level will appear on all Content Types under that level

Each document has a single Content Type (chosen on upload)

Most document libraries (e.g. Legal) support multiple Content Types

Projects Portal (http://projects)

Portal home has overall links, current projects list

Sub-sites similar to teams – one per project

Project documents stored inside “Current Projects” folder in documents portal

Where to next?

Enterprise searching

Knowledge bases, lessons learned

Change request site

Legal document scan to SharePoint

…