Migreren van OutSystems naar .NET

Migreren van OutSystems naar .NET is geen herschrijving — het is een strategische modernisering. Ik leid op dit moment precies deze migratie bij Boskalis, waar we applicaties voor het monitoren van baggermaterieel van OutSystems overzetten naar een moderne .NET-stack. Dit is wat ik heb geleerd over hoe je deze transitie maakt zonder je verstand of je uptime te verliezen.

Waarom migreren van OutSystems?

OutSystems is een capabel low-code platform, en voor veel organisaties is het de juiste keuze. Maar er komt een punt waarop de beperkingen zwaarder wegen dan de snelheidsvoordelen. De meest voorkomende triggers die ik zie zijn oplopende licentiekosten, platformbeperkingen bereiken en moeite om senior developers aan te trekken die met gangbare tooling willen werken.

Bij Boskalis waren de monitoring-applicaties voor baggermaterieel ver voorbij het punt gegroeid waarmee OutSystems comfortabel overweg kan. We hadden te maken met hoogfrequente sensordata van schepen, complexe realtime dashboards en integraties met industrieel materieel — het soort workloads waarbij je fijnmazige controle nodig hebt over prestaties en architectuur. OutSystems is niet gebouwd voor dat niveau van maatwerk.

De licentieberekening is ook moeilijk te negeren. Voor een middelgroot bedrijf dat 5-10 applicaties draait, kan OutSystems-licentie EUR 150.000-400.000 per jaar kosten. Een .NET-stack op Azure met vergelijkbare capaciteit komt doorgaans uit op 30-50% van die kosten als je infrastructuur en developer-tooling meeneemt.

Wanneer op OutSystems blijven

Niet elke OutSystems-applicatie hoeft gemigreerd te worden. Als je app een rechttoe rechtaan CRUD-workflow is met minimale custom logica, is OutSystems waarschijnlijk nog steeds de juiste plek. Ik gebruik een eenvoudig besliskader:

• Blijf als de app minder dan 20 schermen heeft, standaard datapatronen en een stabiele featureset
• Migreer als je custom integraties nodig hebt, high-performance dataverwerking, of het team meer tijd besteedt aan het vechten tegen het platform dan aan het bouwen van features
• Vervang als de app toch end-of-life is en de requirements significant zijn veranderd

Wees eerlijk over de kosten. Een migratie is een investering — doorgaans 3-6 maanden voor een applicatie met gemiddelde complexiteit met een team van 2-3 developers. Als je die tijdlijn niet kunt rechtvaardigen, is een migratie de verkeerde keuze.

Hoe je een OutSystems naar .NET-migratie plant

De allerbelangrijkste stap is je OutSystems-architectuur mappen naar .NET-equivalenten voordat je ook maar een regel code schrijft. OutSystems heeft zijn eigen abstracties, en als je die letterlijk probeert te vertalen, krijg je een rommeltje. Behandel de migratie in plaats daarvan als een kans om goede .NET-patronen te adopteren.

Dit is de architectuurmapping die ik gebruik:

OutSystems-concept	.NET-equivalent	Opmerkingen
Server Actions	ASP.NET Core Minimal APIs of Controllers	Map elke actie naar een endpoint of servicemethode
Client Actions	Blazor-componenten of TypeScript/JS	Hangt af van je front-endstrategie
Entities	Entity Framework Core-modellen	Bekijk relaties — OutSystems verbergt hier complexiteit
Aggregates	LINQ-queries of ruwe SQL	Prestatiekritieke queries hebben vaak handmatig geoptimaliseerde SQL nodig
Screen logic	Razor Pages, Blazor of SPA-framework	Kies op basis van teamvaardigheden en requirements
Site Properties	Configuratie via appsettings.json of Azure App Configuration	Gebruik het strongly-typed options pattern
Timers	Azure Functions of Hangfire	Achtergrondtaken hebben expliciete scheduling nodig
BPT (Business Process Technology)	Workflow engines zoals Elsa of custom state machines	Dit is vaak het moeilijkste onderdeel om te migreren
OutSystems REST/SOAP-integraties	HttpClient met typed clients	Gebruik Refit of NSwag voor nette API-clients

Architectuurbeslissingen die ertoe doen

Bij Boskalis zijn we uitgekomen op ASP.NET Core Web API met een Blazor front-end voor de monitoring-dashboards, met Azure SQL en Azure SignalR voor realtime data. De sensordatapipeline loopt via Azure Event Hubs naar verwerkingsservices.

Een paar architectuurbeslissingen die ons veel pijn hebben bespaard:

Begin met de datalaag. Exporteer je OutSystems-entiteitsmodel en bouw het opnieuw op in Entity Framework Core. OutSystems genereert automatisch veel impliciete relaties en auditvelden — je wilt weloverwogen kiezen wat je behoudt. We hebben ons aantal entiteiten met ongeveer 40% teruggebracht, simpelweg door overtollige OutSystems-scaffolding te verwijderen.

Kopieer het OutSystems-schermmodel niet. OutSystems-schermen bundelen layout, logica en data-ophaling op manieren die niet goed vertalen. Ontleed ze in echte componenten met een duidelijke scheiding van verantwoordelijkheden.

Plan je authenticatie vroeg. OutSystems heeft ingebouwd gebruikersbeheer dat je makkelijk als vanzelfsprekend beschouwt. Wij zijn overgestapt naar Azure AD B2C voor externe gebruikers en Azure AD voor interne gebruikers, geintegreerd via ASP.NET Core Identity. Plan minstens twee weken hiervoor in als je complexe rolstructuren hebt.

Veelvoorkomende valkuilen en hoe je ze vermijdt

De complexiteit van bedrijfslogica onderschatten. OutSystems verbergt veel logica in visuele flows die er simpel uitzien maar tientallen vertakkingsvoorwaarden bevatten. Laat voordat je een module migreert een developer elke flow doorlopen en de daadwerkelijke bedrijfsregels documenteren. Wij vonden ongeveer 30% meer logica dan wat zichtbaar was in de OutSystems-documentatie.

De OutSystems-database-eigenaardigheden negeren. OutSystems gebruikt eigen conventies voor primaire sleutels, soft deletes en auditkolommen. Als je data migreert, schrijf dan vroeg transformatiescripts en test ze tegen datasets op productieschaal. Wij hebben drie volledige datamigratie-repetities gedaan voor de daadwerkelijke cutover.

Alles tegelijk proberen te migreren. Een big-bang migratie is bijna altijd een fout. Wij gebruiken een strangler fig-patroon — nieuwe features gaan in .NET, bestaande features migreren module voor module, en beide systemen draaien parallel achter een gedeelde API gateway. Zo blijft het bedrijf draaien terwijl de migratie vordert.

Prestatiebaselines overslaan. Voordat je een module migreert, benchmark je hem in OutSystems. Na migratie vergelijk je. Als je niet kunt aantonen dat de .NET-versie minstens even goed presteert, heb je een probleem. Wij volgen responstijden, doorvoer en foutpercentages voor elk gemigreerd endpoint.

DevOps- en deploymentstrategie

Een van de grootste voordelen van de overstap naar .NET is eigenaarschap over je deployment-pipeline. OutSystems heeft zijn eigen deploymentmodel dat beperkt hoe je omgevingen en releases beheert.

Onze setup bij Boskalis:

• Azure DevOps voor CI/CD-pipelines
• Infrastructure as Code met Bicep templates
• Gecontaineriseerde deployments naar Azure Container Apps
• Feature flags via Azure App Configuration voor geleidelijke rollouts
• Geautomatiseerde integratietests die tegen elke omgeving draaien

Dit geeft ons deploymentflexibiliteit die simpelweg niet mogelijk was op OutSystems. We gingen van tweewekelijkse geplande releases naar on-demand deployments, soms meerdere keren per dag.

Migratiesucces meten

Volg deze metrieken om te weten of je migratie op koers ligt:

• Feature parity-percentage — welk percentage van de originele functionaliteit is live in .NET
• Prestatievergelijking — responstijden en doorvoer versus de OutSystems-baseline
• Deploymentfrequentie — zou moeten toenemen na migratie
• Incidentpercentage — zou gelijk moeten blijven of afnemen
• Developertevredenheid — bevraag je team, serieus

Bij Boskalis bereikten we 80% feature parity binnen vier maanden voor de eerste grote applicatie, met meetbare verbeteringen in laadtijden van dashboards en doorvoer van dataverwerking.

Veelgestelde vragen

Hoe lang duurt een OutSystems naar .NET-migratie?

Voor een applicatie met gemiddelde complexiteit met 30-50 schermen en matige bedrijfslogica, reken op 3-6 maanden met een team van 2-3 ervaren .NET-developers. Zeer complexe applicaties met uitgebreide integraties of workflow-logica kunnen 6-12 maanden duren. De strangler fig-aanpak laat je stapsgewijs waarde leveren in plaats van te wachten op een volledige cutover.

Kun je OutSystems direct naar .NET migreren zonder te herschrijven?

Nee. Er is geen geautomatiseerde tool die OutSystems visuele logica omzet naar nette .NET-code. Het OutSystems-platform compileert onder de motorkap naar .NET, maar de gegenereerde code is niet onderhoudbaar. Beschouw het als een begeleide herschrijving — gebruik de OutSystems-applicatie als gedetailleerde specificatie, maar bouw de .NET-versie met goede patronen en architectuur.

Welke .NET-vaardigheden heeft het team nodig voor deze migratie?

Je hebt sterke ervaring nodig met ASP.NET Core, Entity Framework Core en je gekozen front-endaanpak — of dat nu Blazor, React of Angular is. Cloudervaring met Azure is belangrijk als je daar host. DevOps-vaardigheden voor CI/CD-pipelines zijn ook essentieel, aangezien je de deploymentverantwoordelijkheid overneemt die OutSystems eerder afhandelde.

Is Blazor een goede vervanging voor OutSystems front-ends?

Blazor is een sterke keuze wanneer je team .NET-gericht is en je in een technologiestack wilt blijven. Het gaat goed om met complexe dashboards en data-intensieve interfaces. Voor publiekgerichte applicaties waar SEO en initiele laadprestaties kritiek zijn, past een JavaScript-framework zoals React of Vue in combinatie met een .NET API mogelijk beter. Wij gebruiken Blazor bij Boskalis omdat de monitoring-dashboards interne tools zijn waar de .NET-vaardigheidsmatch zwaarder weegt dan de afwegingen.

Wat gebeurt er met de OutSystems-database tijdens de migratie?

Je hebt twee opties: de data migreren naar een nieuw databaseschema ontworpen voor je .NET-applicatie, of de bestaande database behouden en de .NET-applicatie ertegen bouwen. Ik raad sterk aan om de data te migreren. Het OutSystems-databaseschema bevat platformspecifieke conventies die op de lange termijn wrijving veroorzaken. Schrijf ETL-scripts, test ze grondig en plan een datamigratie-window in tijdens de cutover.