Het uitvoeren van een datamigratie is voor veel van onze opdrachtgevers niet een dagelijkse bezigheid en zeker geen doel op zich! Normaliter vormt een andere business driver de trigger voor het uitvoeren van een datamigratie. Denk hierbij aan de vervanging van legacy systemen of de samenvoeging van bedrijfsactiviteiten. Een effectieve uitvoering van de bedrijfsprocessen in de nieuwe situatie is vaak het doel, de noodzaak voor bruikbare data wordt veelal gezien als (zelfs nare) bijkomstigheid. Toch vormt de datamigratie een belangrijke
Je hoort het maar al te vaak: “Als ik het mocht overdoen…” of “Als ik dat eerder had geweten…”. Dit geldt zeker voor datamigraties. Dit is voor veel organisaties meestal een eenmalige activiteit. En juist als je iets voor het eerst doet, dan stap je in die valkuilen en maak je -maar al te begrijpelijk- ‘beginnersfouten’. Wat zijn de belangrijkste valkuilen van een datamigratie? “De data kwaliteit valt buiten de scope” Verreweg de belangrijkste valkuil is het negeren van de
Als datamigratie specialist komen we het maar al te vaak tegen: De opdrachtgever start een implementatietraject, waar datamigratie een noodzakelijk onderdeel van is. Zonder naar de daadwerkelijke brondata te kijken wordt aangenomen dat deze data voldoet aan de algemeen geldende business rules. De migratiestrategie en migratiespecificaties worden op basis van deze aanname (en daarmee theoretische situatie) opgesteld. Vervolgens wordt de migratieprogrammatuur gebouwd en worden de eerste test- en proefmigraties gestart. En wat blijkt: ontzettend veel uitval! Enerzijds vanwege (een gebrek
Als geen ander kunt u uw eigen data interpreteren. U weet immers wat de betekenis is van de gegevens en waar ze voor staan. Zelfs wanneer u dat niet exact (meer) weet, bijvoorbeeld omdat een systeem automatisch data of tags heeft gegenereerd. Of de interpretatie van de invoervelden per collega verschilde, of omdat er meerdere fusies zijn geweest. Zelfs dan weet u het nog steeds veel beter dan menig ander. Maar u heeft geen tijd en besluit een partij in
De situatie Stel je de volgende situatie eens voor: Er is een nieuwe applicatie in gebruik genomen die een of meerdere bestaande applicaties vervangt. Die oude applicaties zijn echter nog niet uitgeschakeld want er zit nog data in. Een datamigratie blijkt een kostbaar project te zijn en de beslissing hierover wordt nog even uitgesteld. Mag ik een alternatief voorstellen? Het alternatief Een raadpleegomgeving om de data uit de oude systemen te bekijken, bijvoorbeeld in de vorm van een eenvoudige desktop-
U voert zelf een datamigratie uit, of u laat een datamigratie uitvoeren door een externe partner of leverancier. Maar hoe toont u aan dat alle gegevens juist, volledig en controleerbaar zijn overgezet? En wie toont dit aan? Biedt uw conversiepartij hiervoor een passende oplossing? Controle en bewijsvoering bij datamigraties is belangrijk om aantoonbaar vast te stellen dat de conversie van de gegevens juist, volledig en controleerbaar heeft plaatsgevonden. Richting stakeholders (bijv. business, gebruikers, auditors, accountants) vormt de controle en bewijsvoering
Het bepalen van de juiste laadstrategie is cruciaal. Een belangrijke overweging bij een datamigratie of dataconversie is de wijze waarop de geconverteerde gegevens in de doelomgeving worden geladen. Dit wordt wel de laadstrategie genoemd. Wat voor laadstrategieën zijn er eigenlijk en welke is bij een datamigratie de beste optie. Bij verschillende klanten heb ik als datamigratie consultant gediscussieerd en geadviseerd over dit onderwerp. Mijn ervaringen heb ik nu opgeschreven in een artikel dat is gepubliceerd door Computable. Via deze link
In mijn vorig blog haalde ik het al aan; mijn werk als datamigratie consultant is eigenlijk dat van een verhuizer in de IT. Daarbij kijken we in het grote geheel gevoelloos naar de data en scoren het liefst door af en toe wél ons best te doen om verder te kijken dan de requirements. Maar er zijn meer parallellen te vinden. Afgelopen week volgde ik weer eens een seminar over performance analyses binnen Oracle. Hartstikke interessant met veel leuke tools
Brandstof is de energie van auto’s zoals testdata energie is voor het testen van software! Over de noodzaak van testen hoeven we het tegenwoordig gelukkig niet meer te hebben. Nagenoeg iedere organisatie is er wel van overtuigd dat je nieuwe producten eerst uit moet proberen om er achter te komen dat het product wel doet wat we er met z’n allen van verwachten. En dat er geen rare fouten in worden gemaakt die de zorgvuldig opgebouwde naam van het bedrijf
Het ontbreken van goede testdata-sets kan een grote belemmering vormen voor een efficiënt en effectief testproces. Vooral Agile-trajecten, met steeds kortdurende ontwikkelintervallen, brengen dit fenomeen vaak pijnlijk duidelijk aan het licht. Als je bij het maken van testdata-sets gebruik kunt maken van productiedata, dan heeft dat als groot voordeel dat de data al bestaan, heel representatief zijn en alleen nog maar naar een testomgeving gekopieerd hoeven te worden Maar testen met een volledig productie-kopie is doorgaans niet efficiënt, vanwege het