Legacyapplicaties moderniseren betekent niet alle software in één keer herschrijven. Voor veel bedrijven is de betere eerste vraag welke functie moet veranderen, wat voorlopig kan blijven draaien en hoe een order tijdens de overgang correct blijft. DAXS zou een bestaande Windows- of Linux-applicatie daarom eerst onderzoeken op data, interfaces en fabrikantgoedkeuringen voordat een nieuwe gebruikersinterface, API of platform wordt gekozen.
Een bestaande VM verplaatsen kan besturingssysteem en hardware loskoppelen, maar moderniseert de applicatie zelf nog niet. De acceptatie van een VMware/Proxmox-migratie is een afzonderlijke stap. Hier gaat het om langduriger veranderingen aan functies en integraties terwijl het bedrijf blijft werken.
Eerst de omgeving beschrijven, dan een grens trekken
Een inventarisatie vraagt meer dan een lijst servernamen. Voor iedere dienst horen eigenaar, gebruikersgroepen, Windows- of Linux-versie, database en drivers, batchtaken, bestandsshares, printers, identiteitsbron, inkomende en uitgaande interfaces en onderhouds- en licentiecontracten in een applicatiekaart. Vooral minder zichtbare routes tellen: een nachtelijke CSV-export naar de boekhouding, een serviceaccount met een aflopend wachtwoord of een werkplekclient waarvan de versie aan de server is gekoppeld.
Bij propriëtaire software bepaalt de fabrikant welke gastbesturingssystemen, databaseversies, drivers en virtualisatieomgevingen worden ondersteund. Rechtstreeks schrijven in diens database lijkt misschien eenvoudig, maar kan bedrijfsregels, garantievoorwaarden en latere updates schenden. DAXS zou eerst een gedocumenteerde API, goedgekeurde export of fabrikant-SDK beoordelen. Ontbreekt ieder ondersteund integratiepunt, dan kan stapsgewijze vervanging technisch of contractueel ongeschikt zijn; een andere keuze met de leverancier is dan nodig.
Een voorbeeld: orderstatus vernieuwen, orderkern behouden
Stel dat intern orderbeheer een Windows-applicatiedienst, een SQL-database en een nachtelijke export heeft. Klanten vragen vaak naar hun orderstatus, terwijl de oude kern orders en facturen betrouwbaar verwerkt. De eerste nieuwe functie kan een alleen-lezen-statusweergave zijn die via een goedgekeurde interface wordt gevoed. De orderkern en zijn database blijven voorlopig leidend.
Een integratielaag vertaalt oude identificaties en statuswaarden naar een gedocumenteerd nieuw model. Dit staat bekend als adapter of Anti-Corruption Layer. Het is geen magische API voor een onbeheerde database: rechten per order, authenticatie, invoercontrole, snelheidslimieten, logging en responstijden moeten opnieuw worden getoetst. OWASP noemt objectgebonden autorisatie en authenticatie als belangrijke API-risico’s. Ook een statusvraag die alleen leest mag geen orders van anderen blootleggen.
Pas wanneer de leesfunctie stabiel is, kan een afgebakend schrijfproces volgen, bijvoorbeeld de invoer van één ordertype. Dataregie wordt nu doorslaggevend: zolang de oude kern leidend is, mag de nieuwe interface niet stilzwijgend een tweede onafhankelijke waarheid maken. Leg voor elk record vast welk systeem mag schrijven, hoe aanvragen eenduidig worden herkend en hoe mislukte pogingen, vertraagde berichten en correcties worden afgestemd. Beide systemen tegelijk laten schrijven is zonder een bedrijfsmodel voor conflicten geen overgangsplan.
Vier fasen met een meetbaar stoppunt
| Fase | Wijziging | Bewijs vóór de volgende fase |
|---|---|---|
| 1. De bestaande omgeving veiligstellen | Afhankelijkheden, contracten, datastromen en herstelbare back-ups vastleggen | Applicatie en database herstellen in een testnetwerk; een voorbeeldorder met de business controleren |
| 2. Lezen loskoppelen | Goedgekeurde export/API voor de nieuwe statusweergave gebruiken | Status, inzagerechten, actualisatievertraging en belasting vergelijken met het oude systeem |
| 3. Eén schrijfgeval verplaatsen | Slechts één ordertype via de nieuwe interface afhandelen; dataregie vastleggen | Iedere order precies eenmaal boeken, documenten en correcties afstemmen, terugweg oefenen |
| 4. Het oude onderdeel afbouwen | Pas uitschakelen na aantoonbare overname van functies en data | Geen onopgeloste verborgen aanroepers, export-/bewaarplichten of fabrikantafhankelijkheden |
Deze geleidelijke vervanging van functies lijkt op het Strangler Fig-patroon. Het past niet overal: als aanvragen niet omgeleid kunnen worden, de leverancier elke interface blokkeert of het kleine systeem eenvoudig geheel te vervangen is, kan een adapter meer kosten dan opleveren. De overgangslaag vraagt zelf monitoring, capaciteit en een beheerder; zij mag geen nieuw single point of failure worden.
De terugweg vastleggen vóór de eerste productieschrijfactie
Bij een alleen-lezen-statusweergave is de terugweg vaak eenvoudig: de nieuwe weergave uitschakelen, de orderkern blijven gebruiken en de oorzaak onderzoeken. Na de eerste schrijfactie in een nieuwe database is een proxy terugschakelen onvoldoende. Nieuwe orders, annuleringen en documenten moeten in de oude toestand worden teruggebracht of door de business worden afgestemd. Iedere overgang vraagt daarom een laatste afgestemde datastand, een duidelijke schrijfstop, export-/importprocedures, verantwoordelijken en een oefening. Microsoft waarschuwt uitdrukkelijk dat rollback moeilijker wordt zodra oude dataobjecten verwijderd zijn.
Ook de oude omgeving moet aandacht houden tijdens parallel bedrijf. Krijgen besturingssysteem of applicatie geen beveiligingsupdates meer, beperk en bewaak dan gericht de betrokken diensten, netwerkpaden en toegangen en leg een einddatum vast. Een nieuwe API ervoor verwijdert de kwetsbaarheid in de oude kern niet. Of isolatie volstaat, hangt af van het concrete risico en de beschikbare fabrikantmaatregelen.
Inspanning en grenzen eerlijk beoordelen
Een vergelijking over drie of vijf jaar bevat minstens inventarisatie, fabrikant- en licentieafstemming, adapterontwikkeling, datamapping, beveiligingscontrole, testdata, bedrijfsacceptatie, parallel bedrijf, monitoring en latere afbouw. Nieuwe besturingssysteem- of databaselicenties en opleiding van mensen die tijdelijk beide omgevingen beheren kunnen daarbij komen. Parallel bedrijf is een expliciete kostenpost, geen gratis tussenfase. Stapsgewijs vernieuwen loont alleen wanneer vermeden risico’s en nieuwe functies de werkelijke inspanning rechtvaardigen; een algemeen besparingspercentage volgt daar niet uit.
DAXS zou met de business een kleine, zichtbare eerste grens kiezen, zoals de statusvraag uit het voorbeeld, en deze beoordelen op correcte data, responstijd, ondersteunbaarheid en herstel. Daarna wordt bepaald welke volgende functie echt een eigen dienst nodig heeft. Voor de technische basis van een bestaande VM biedt Proxmox in bedrijven het infrastructuurkader; API-toegang planbaar beheren vult het latere interfacebeheer aan. Wie een concrete applicatiekaart wil opstellen, bereikt DAXS via Contact.
Bronnen: Microsoft Azure Architecture Center: Strangler Fig-patroon · Microsoft: Anti-Corruption Layer-patroon · OWASP: API Security Top 10.
