Het creëren van een nieuwe, op een CMS gebaseerde website, brengt vaak met zich mee dat bestaande inhoud gemigreerd moet worden naar het nieuwe CMS. Het is begrijpelijk dat de nadruk bij ontwikkeling ligt op de nieuwe features. Migratie wordt vaak benaderd als op zich staand naast de rest van het project. Dit resulteert echter in onnodige risico’s. Om deze te verkleinen worden in dit artikel een aantal aspecten belicht waarmee een strategie voor migratie kan worden opgesteld.

– Plan van aanpak voor migratie –

Worst case waterval

Wees eerlijk: migratie wordt niet beschouwd als kinky door de software developers. Hun verlangen om de klant tevreden te stellen wordt maar al te gemakkelijk opgebruikt door de zwaarwegende aspecten van feature development, performance, robuustheid en gebruiksvriendelijkheid.

Deze situatie past verleidelijk goed in een waterval aanpak. Gegeven dat de originele website constant wordt gemodificeerd, waarom niet wachten totdat het project – zoals gezien door de ogen van de developer – klaar is om pas daarna de migratie uit te voeren. Of nog verlokkender, laat het migreren over aan de klant.

Iets minder passief is het uitstellen van de migratie totdat het nieuwe domein model en database schema stabiel zijn.

Risico’s en RUP

De waterval aanpak stelt de risico’s geassocieerd met migratie uit tot het eind van het project. Daardoor worden de nadelige effecten versterkt.

De basis vragen aangaande de migratie zijn:

• Migreren we alle data die we zouden moeten doen? En,
• Is de data correct gemigreerd?

Mogelijke problemen omvatten het falen van het migreren van een deel van de data en het opslaan van data in het nieuwe CMS welke niet correct wordt weergegeven in het nieuwe grafische design. Om deze problemen op te lossen kan het nodig zijn om veranderingen aan te brengen in delen van het project die eerder gereed zouden moeten zijn, b.v. aan het data model, het grafisch design of aan het interactie model.

Het aanpakken van deze risico’s raakt meer dan alleen het migratie proces zoals:

• De originele applicatie bevat goed doordachte features die specifieke eisen van de klant implementeren.
• Geïmporteerde data maakt het mogelijk het nieuwe data model te testen.
• Geïmporteerde data maakt het mogelijk het nieuwe grafisch design te testen.
• Geïmporteerde data biedt een representatieve data set voor het testen van performance.

Migratie kan dus niet alleen tot risico’s leiden maar biedt het ook mogelijkheden ter verbetering van het ontwerpen en implementeren van het nieuwe systeem. Het is daarom verstandig om de migratie te verplaatsen naar het begin van het project en dit bij elke stap te herhalen.

– Fasering van migratie –

Start

De focus van dit artikel ligt op het werk van een website-developer die werkt voor een klant. Dat kunnen allebei organisaties zijn.

De startfase begint met een Request for Proposal (RFP) van de klant en eindigt met het Developer’s Proposal. Gezien de strekking van dit artikel wordt ervan uitgegaan dat de klant al een website heeft, dat het RFP een nieuwe site betreft met een (ander) CMS, en dat de migratie zin heeft.

Handmatige migratie door web editors die vanuit het oude systeem kopiëren en in het nieuwe plakken is een mogelijkheid die serieus genomen moet worden. Een groepje editors kan veel bereiken in een paar dagen en deze methode garandeert dat alle content “visueel�? is gecontroleerd door diegenen die het beste kunnen beoordelen of dit correct is uitgevoerd.

Indien deze route wordt gekozen wordt de migratie duidelijk verplaatst naar de transitie fase van het project, omdat de data van de huidige website nog aangepast wordt gedurende de bouw van de nieuwe site. Om het risico van het opduiken van problemen te verminderen dient als alternatief voor migratie ter toetsing vroeg in het project een data set beschikbaar te komen welke de klant als relevant erkent.
Omdat de web editors –werkend voor de klant – de migratie uitvoeren hoeft de web developer deze niet te plannen.

Alhoewel er een goede reden kan zijn voor een copy-paste migratie zou dit over het algemeen om bovenstaande redenen vermeden moeten worden. Indien de klant zo’n migratie prefereert of het punt van migratie helemaal niet benoemt in het RFP, dan zou de developer moeten overwegen om de klant voor te stellen de migratie deel uit te laten maken van het project. Dat zal helpen een beter passend product te leveren en onverwachte vertragingen later in het project te verminderen.

Om het migratie gedeelte van het voorstel te maken, de deliverable van deze fase, moet de developer:

• Toegang verkrijgen tot de over te zetten data. Mogelijk uit de database, maar anders uit de huidige website.

Complexiteit inschatten. Verschillende onderdelen benoemen en voor elk onderdeel inschatten hoe moeilijk het zal zijn om te migreren naar de nieuwe CMS.

• Het migratie proces plannen. Duidelijke omgrensde onderdelen kunnen gemigreerd worden voor een fixed-price fee. De andere onderdelen zouden meer onderzocht moeten worden tijdens de uitvoeringsfase. Dit kan resulteren in een fixed-price fee op basis van een migratieontwerp voor de rest van de migratie of een fee geheel of gedeeltelijk gebaseerd op na-calculatie.
• De opdrachtgever “mee�? krijgen. In het geval van de migratie betekent dit dat de klant akkoord moet gaan met het voorgestelde migratieproces. Indien onduidelijke onderdelen een aanzienlijk deel uitmaken van het proces zou ernstig overwogen moeten worden om de klant te overtuigen dat een fixed-price fee een onevenredig risico legt bij de developer. De prijs die betaald wordt voor het indekken tegen prijsrisico door de klant is dat later in het project conflicten kunnen ontstaan wanneer de developer tegenslagen bij de migratie volledig voor eigen rekening moet nemen. Dergelijke conflicten kunnen een negatieve uitwerking hebben op het verloop van het project.

Uitvoering

Wanneer de klant het voorstel geaccepteerd heeft is, over het algemeen, de eerste taak een gedetailleerde planning en design te schrijven. RUP geeft de mogelijkheid een vaststaand gedeelte van de implementatie uit te voeren tijdens deze fase en dat is precies wat er moet gebeuren voor de migratie.

Informatie over zowel de over te zetten data als de nieuwe website is beschikbaar maar zal naar alle waarschijnlijkheid niet compleet zijn op dit punt in het project. Dit zou, voor een gedeelte, benaderd moeten worden door boven water te krijgen hoe de over te zetten website is opgeslagen, hoe deze is gestructureerd, hoeveel er over te zetten is en hoe de data kan worden aangepast aan het standaard design van het CMS.

Het is onwaarschijnlijk dat deze taak afgerond kan worden gedurende deze fase. Bovendien, alleen een functioneel compleet CMS zal de test mogelijk maken of de migratie optimaal is uitgevoerd. De migratie kan daardoor niet worden afgerond in de vroege stadia van een “waterval�? aanpak van het project.

Gelukkig kunnen goede resultaten verkregen worden door alert te reageren indien de migratie vroeg wordt gestart en dit te herhalen tijdens alle daaropvolgende fasen.

Gedurende de uitvoeringsfase zou het volgende bereikt moeten worden:

• Het verkrijgen van een model van de oorspronkelijke data. Indien een dergelijk model niet beschikbaar is zou het uit de beschikbare data opgesteld moeten worden.
• Het verkrijgen van het nieuwe data model. Indien er geen data model van het nieuwe CMS beschikbaar is zou dit gemaakt moeten worden.
• Het bouwen van de migratie tool. Het ontwerpen en implementeren van een migratie tool gebaseerd op de bovengenoemde modellen.
• Lijst maken van web-page patterns. Een lijst van structureel verschillende presentaties van de data, gescheiden in dat wat wel en dat wat niet automatisch gemigreerd kan worden.

De implementatie van de tool zou aanpassingen moeten kunnen toestaan:

• De datastructuur van het nieuwe CMS zou kunnen veranderen.
• De oorspronkelijke datastructuur zou niet helemaal begrepen kunnen zijn, b.v het zou additionele informatie kunnen bevatten dat bewaard zou moeten blijven.
• Markup in de oorspronkelijke data zou verdere opschoning, omzetting of uitschakeling vereisen.

De uitvoeringsfase zou moeten resulteren in:

• Een werkende implementatie van de migratie tool
• Een lijst van web-page patterns
• Een planning van de rest van de migratie.

Omdat migratie veel onbekende factoren heeft is het moeilijk om de uitvoering te plannen. Echter, gegeven de gedeeltelijk werkende implementatie en de pattern-list, kan in ieder geval rekening gehouden worden met de bekende factoren. Hiervoor kan een fixed-price planning worden gemaakt. Dit resulteert in een duidelijke begrenzing van wat er gemigreerd moet worden waardoor het risico op conflicten wordt verminderd. Alle werkzaamheden die buiten de op deze manier begrensde scope vallen zouden moeten worden gebaseerd op na-calculatie.

Bouw

De migratie tool zou functioneel moeten zijn bij aanvang van de bouwfase. Dit levert een uitstekende data set voor het testen van het gedrag van het grafisch design wanneer deze wordt toegepast op echte data, het testen van de speciale modificaties in de administratie interface van het CMS, het testen van toegevoegde data-gerelateerde functionaliteit zoals zoeken, en het testen van de performance.

Transitie

Als de nieuwe CMS-gebaseerde applicatie klaar is en is ingezet op de productie systemen zou de migratie tool nog één keer moeten draaien om de klus van de developer te beëindigen. Na al deze herhalingen zou dit een fluitje van een cent moeten zijn, toch?

Ah, ja. Maar op twee issues moet men zeker zijn voorbereid. Ten eerste, als de applicatie eenmaal is verplaatst naar de productie systemen dan zou de migratie tool niet meer functioneel kunnen zijn. Als het moet werken op deze apparaten, vergeet dan niet te controleren bij de beheerders van de systemen dat dit ook inderdaad mogelijk is. Als ook voor deze stap de migratie tool draait op het test systeem, dan zal de resulterende database moeten worden verplaatst naar het productie systeem. Zorg er dan ook voor dat er tijd beschikbaar is voor zo’n verplaatsing, aangezien uren erg kostbaar kunnen zijn in dit stadium. Controleer tevens of er geen afhankelijkheden van het migratiesysteem, zoals URL’s uit de test machine- in de data zijn geslopen tijdens de migratie.

Op de tweede plaats, zorg ervoor dan de klant de migratie heeft geaccepteerd voordat er enige handmatige editing aan de site plaats vindt. Na dat laatste is een weg terug moeilijk!

– Verbetering van het proces –

Het migratie proces kan vereenvoudigd worden door de beschikbaarheid van een standaard migratie tool voor het gekozen CMS. Het creëren van zo’n tool wordt mogelijk gemaakt door een combinatie van de volgende factoren:

1. Aanvankelijk beschikbaar data model van het nieuwe CMS.
2. Goede data entry interface voor het nieuwe CMS
3. Crawler and parser. Omdat de oorspronkelijke data wordt geacht te verschijnen op een website kan een standaard crawler and parser worden ontwikkeld om de site snel te scannen en data te extraheren.
4. Lijst van web-page patterns. Onderhoud een standaard controlelijst van webpage patterns welke ook is geïmplementeerd als deel van de standaard migratie tool. Bijvoorbeeld, de meest voorkomende patterns zijn artikel-detail en lijst-van-artikelen.

– Conclusie –

Migratie van oorspronkelijke data naar een nieuw CMS zou vroeg in het bouwproces moeten worden uitgevoerd om risico’s te verminderen. Tijdens elke herhaling van het project zou de migratie tool moeten worden verbeterd om de laatste kennis van zowel de oorspronkelijke omgeving als het nieuwe CMS te weerspiegelen. Omdat migratie factoren kan betreffen welke pas in de loop van het project boven water komen dient het onderdeel bij voorkeur gedeeltelijk plaats te vinden op basis van fixed-price en gedeeltelijk op basis van nacalculatie.
De proces kan worden vereenvoudigd door het hebben van een goed design van het gekozen CMS, het gebruik maken van een checklist van gebruikelijke web-page patterns en de beschikbaarheid van de standaard crawler-based migratie tool voor het CMS.

Bronnen

• “The Rational Unified Process Made Easy�? (2003) Per Kroll and Philippe Kruchten, Addison-Wesley
• “Agile Legacies: Using Iterative Methods to Import Legacy Data�? (2006), John Ferguson Smart, java.net 3 Feb 2006

Ik wil Erik van Oosten bedanken voor het demonstreren van een systematische aanpak van een migratie en Wilma Noordam voor de vertaling uit het Engels.