Je kunt het! Contentmigratie in 6 stappen

Sta je aan de vooravond van een migratietraject? Tussen twee websites, of naar een nieuw intranet? En werk je in een organisatie waar niet een hele projectorganisatie rondom de migratie is gevormd, met bijbehorend budget? Oftewel: je moet roeien met de riemen die je hebt? Geen nood, je kunt het. In dit artikel krijg je een aantal handvatten over de te doorlopen stappen tijdens een migratietraject.

Maar eerst nog even een inleiding.  Er is al eerder over contentmigratie geschreven, hier op Frankwatching. Over monsterlijke situaties die zich kunnen voordoen. Maar ook over gespitst zijn op behoud van de SEO en het uit de weg ruimen van dode links, en alles wat maar van een bord kan vallen tijdens een migratietraject.

Migreren = projectmanagement

In de commentaren op het eerder genoemde ‘monster’-artikel werd beaamd dat een migratietraject ontzettend mensenwerk is. Maar het is ook ontzettend projectmatig werk, wat duidelijk projectmanagement behoeft. In grote organisaties, waar omvangrijke migraties worden gedaan, is de optuiging van een officieel project met bijbehorende business case, scope, Project Initiatie Document, projectteam en de whole shebang een absolute must.

Omdat mensen dit soort projecten er gewoonweg niet ‘bij’ kunnen doen. Omdat een communicatiemedewerker niet automatisch een uitstekend projectleider is. En omdat iemand de voortgang en budgetten moet kunnen verantwoorden, en zowel met migreerders als programmeurs (of de partijen of bureaus die hen vertegenwoordigen) moet kunnen praten.

Blij worden van planningen maken en nadenken over processen

Maar er zijn voldoende kleine(re) organisaties die een migratieproject zelf tot uitvoer moeten zien te brengen. Vaak naast hun reguliere werk. En dat is nog best wel eens een uitdaging. Want je hoeft echt niet meteen een PRINCE2 deskundige te zijn, maar je moet wel een beetje blij worden van planningen maken, migratiedocumenten inrichten, nadenken over alle (werk)processen. En kunnen praten met designers, programmeurs, bouwers en softwarespecialisten. Iets wat niet iedereen dagelijks doet.

Met dit artikel hoop ik je een aantal dingen mee te kunnen geven waar je tijdens een dergelijke proces op kunt letten. Wel héél erg compact, want anders ben je tot sint-juttemis nog aan het lezen. Ik ga er dus even vanuit dat de migratie gaat om een zoveel mogelijk één-op-éénmigratie, of ‘as-is’ in ICT-termen.

Wat valt niet onder migratie?

In dit artikel valt niet onder migratie:

• Het bouwen van een volledig nieuwe website met glimmende nieuwe content;
• Het implementeren van alleen een nieuw (web)design.

Wat valt wel onder migratie?

‘A website migration is the transfer of content, sites/sections, functionality, team, templates, information architecture, and relationships from one platform to another’ aldus David Hobbs, die het Migration Handbook schreef.

Dit e-book is een absolute aanrader voor iedereen die met een migratie in aanraking komt. Het benoemt duidelijk de processen tijdens een migratieproject en geeft praktische handvatten voor het uitvoeren van de migratie. Volgens Hobbs kunnen migraties horribly wrong gaan, lezen dus. Dat was alvast tip 1.

Een volledig projectplan in dit artikel optuigen gaat niet, want daarvoor is iedere migratiesituatie te uniek. En hoe je komt tot een goede informatiearchitectuur en interactieontwerp, laat stáán een heldere online strategie en duidelijke doelstellingen voor dat nieuwe digitale middel, dat gaan we allemaal nu niet doen. Of hoe je wilt omgaan met content en foto’s en huisstijl en de hele rataplan. Dat zie ik als stap 0, voorafgaand aan het migratietraject.

Is die stap gezet, en staat de migratie voor de deur, dan is hierin een aantal projectmatige basisdingen om over na te denken, af te vinken, plat te slaan, aan te vliegen en in te regelen. Deze benoem ik hieronder, in 6 stappen.

1. Zet je website of intranet op dieet

Vaak worden intranetten en websites in de loop der tijd een oerwoud van informatie. Gebruik dit moment om eens flink de bezem door je content te halen. Zet goed op een rij welke content gemigreerd moet worden. Ruim rigoreus op -want dat is vaak hard nodig-, en actualiseer de content. En ja, dat is een project op zich. Zet je website of intranet op dieet. Gooi weg wat wegkan, vooraf of tijdens de migratie. Bepaal criteria voor de content die meemoet: is het bijvoorbeeld relevant voor je gehele doelgroep, is er een informatie-eigenaar, is het actueel? Wellicht kan dit artikel: ‘The Web Diet’ je hierbij helpen.

2. Maak een projectplan

Start dan met een basisplan voor je migratie. Bepaal hierin de scope, benoem de rollen en verantwoordelijkheden van migreerders en wat de randvoorwaarden zijn om dit project goed tot uitvoer te brengen. Maar ook hoe je wilt omgaan met content en functionaliteiten vanuit de informatiearchitectuur en het design. Benoem deze één voor één, gebruik hiervoor bijvoorbeeld je technisch- en functioneel ontwerp als basis. Wijs ook de mensen aan die fungeren als inhoudelijk expert of informatie-eigenaar van de content. Die dus vragen kunnen beantwoorden over content en daarvoor beschikbaar zijn.

En maak een planning. Een realistische graag. Bespreek ook met de bouwer van je site of intranet op welk moment je bepaalde content kunt gaan vullen. Jij en de bouwer moeten elkaar niet in de weg zitten, maar het is wel fijn als je duidelijk hebt op welk moment in het traject je content kunt plaatsen. En welke content zeker live moet staan bij livegang, en welke eventueel  in een later stadium geplaatst kan worden. Het plan hoeft niet een heel boekwerk te worden, maar benoem de belangrijke zaken. Daar word je manager vaak ook heel blij van.

David Hobbs bespreekt in zijn boek ook de inrichting van een pilot, waarin je dingen uit kunt testen voorafgaand aan het werkelijke migratietraject. Eerlijk gezegd denk ik dat voor veel organisaties niet realistisch is, maar als je tijd en de middelen hebt dan juich ik absoluut het inrichten van een pilot toe.

3. Maak een contentmigratiedocument

Maak daarna, bijvoorbeeld in Excel, een werkdocument aan. Bekijk ook eerst welke pagina’s of content automatisch overgezet kan worden en bespreek dit met de bouwer. Hierop hoef je dan alleen een check te doen ter controle. Bij kleine sites zal dit niet heel snel voorkomen, en zul je waarschijnlijk alle content met de hand willen migreren. Maar toch, misschien is het een optie. Het is even lastig van een afstand te bepalen hoe je je migratiedocument indeelt, maar daarin kan je keuzes maken. Een aanzet:

• Maak een tabblad aan waarin je de nieuwe navigatiestructuur als uitgangspunt neemt en onder elkaar zet (kopieer hierin bijvoorbeeld de informatiearchitectuur).
• Maak ook een ‘spiegeldocument’ , waarin je de oude structuur op een rij zet, en daarachter aangeeft of het al dan niet gemigreerd wordt en zo ja, waar het in de nieuwe structuur terechtkomt. Op deze manier mis je niet ineens een aantal pagina’s die niet mee zijn gekomen uit de oude omgeving.
• Maak kolommen aan voor de te zetten stappen tijdens het migratieproces. Hierin benoem je bijvoorbeeld:
  – Wie de betreffende pagina of content migreert (met functie, naam of initialen).
  – Vanuit welke URL moet content gemigreerd worden? Of vanuit welk document?
  – Prioriteit van het vullen van de pagina: hoog/midden/laag (geef het eventueel kleuren mee).
  – Is de content geplaatst?
  – Is alle metadata aangevuld (aan de hand van de taxonomie!)?
  – Zijn hyperlinks, foto’s, filmpjes geplaatst en gecheckt?
  – Opmerkingen van de migreerder aan de projectleider.
  – Heeft de eindredacteur/projectleider/manager/ieder die zijn ‘plasje’ wil doen de uiteindelijke pagina bekeken en beoordeeld?
  – Is er akkoord voor livegang?

Deze indeling is uiteraard maar een aanzet, omdat, zoals eerder gezegd, ieder migratietraject uniek is, iedere organisatie anders, en iedere projectleider een bepaalde manier van werken heeft.

Maak ook tabbladen aan voor documenten, functionaliteiten (bijvoorbeeld widgets), formulieren, nieuwsberichten, kalenders en overige aparte content die een ander migratieproces hebben. Pas bij ieder tabblad de kolommen met de te doorlopen stappen hierop aan. Onderschat dit niet! Vaak worden formulier en documenten er even ‘bij’ gedaan en verslik je je in de hoeveelheid werk die het met zich meebrengt.

Vind je dat het werken met tabbladen ervoor zorgt dat je alsnog een monsterlijk document krijgt, maak dan aparte Exceldocumenten aan voor ieder type content of functionaliteit. Het is maar net waar je zelf gelukkig van wordt. Want dat is belangrijk tijdens een migratietraject: dat je gelukkig blijft en het jezelf zo makkelijk mogelijk maakt.

4. Vorm een ‘migratieteam’

Vaak moet een aantal collega’s worden aangewezen, of worden mensen ingehuurd, om te ondersteunen bij de migratie van content. Bekijk dan goed welke mensen je hiervoor intern aanwijst. Een logische eerste stap is het vrijmaken van de huidige web- of intranetredacteuren voor een bepaalde tijd. Ja, vrijmaken. Van andere taken dus. Binnen de migratieperiode in je projectplan moeten mensen minstens zoveel dagdelen dedicated zich met de migratie bezig kunnen houden. Anders haal je het nooit. Handjes nodig? Huur dan webredacteuren in die je gedurende een korte periode kunnen meehelpen.

Ga je over naar een nieuwe beheerstructuur na livegang? Met bijvoorbeeld meer decentrale redacteuren die dit werk eerder nog niet hebben gedaan? Betrek dan ook hen tijdens het migratietraject. Zodat ze het cms al goed leren kennen, weten waarom sommige keuzes zijn gemaakt en na migratie vlekkeloos het dagelijks beheer op kunnen pakken. Als fijne bijkomstigheid zorg je zo vroegtijdig voor draagvlak en de motivatie om je website of intranet up to date te houden.

5. Aan de slag

Ja, je moet een keer beginnen. En doe het dan meteen goed. Ga met je team een hele week, of twee, of drie bij elkaar zitten voor de migratie. Zodat je overzicht houdt over alle zaken die lopen. Tijdens een migratie komen vaak bugs naar boven, ontbrekende dingen, zaken die niet lopen, gekke dingen in het cms. Wanneer je die meteen kunt adresseren bij de bouwer, of in ieder geval onder elkaar kunt zetten in een loglijst, behoud je het overzicht.

En oh ja, vooraf training krijgen in het (nieuwe) cms door iemand die er verstand van heeft, plus een training ‘schrijven voor het web’ of iets van dien aard kan ook erg handig zijn. ’s Ochtends de training, ’s middags aan de slag. Hou de cms-deskundige die middag er nog bij, dan kan hij of zij je team direct verder helpen. Ja, dat kost geld, maar dat is de investering dubbel en dwars waard. Eenmaal aan de slag houd je de voortgang bij in het contentmigratiedocument. Zo krijg je in inzicht in de uitdagingen en risico’s en zaken die direct, of later opgelost kunnen worden.

6. Doel behaald!

Content gemigreerd? Super! Scheld en foeter nog een paar keer, trek dan de champagne open, boek een massage of vakantie, en wees opgelucht en blij dat je dit varkentje gewassen hebt.

Stiekeme stap 7: Beheer

Fijn. Je hebt een mooie nieuwe site of intranet, met opgeschoonde content en gebruiksvriendelijk middel tot-en-met. Laat dan geen steken vallen door niet optimaal het beheer in te richten. Start dus vervolgens met de implementatie van je beheer- en governanceplan, en de uitvoer van je redactierichtlijnen door al je redacteurs. Hierover uitweiden zal ik hier nu nog maar niet doen, kom eerst maar eens even rustig bij. (Wil je toch inspiratie? Lees dan mijn artikel over governance eens door).

Heb je ervaring met soortgelijke trajecten en heb ik iets onmisbaars over het hoofd gezien? Of heb je verder tips en aanvullingen? Laat het weten in de reacties!

Foto intro met dank aan Fotolia