Tijdens een migratie bewaak je twee omgevingen, de meeste tools dekken er één
Data monitoring software die ontworpen is voor een steady-state omgeving wordt een blok aan het been tijdens cloud migratie. Het patroon dat we zien: teams kiezen een tool die past bij de beoogde stack (vaak Azure-native), en ontdekken dan dat de legacy on-prem helft donker is geworden.
Cloudmigratieprojecten hebben zelden een schone overgangsdatum. De realiteit voor de meeste organisaties die overstappen van on-premise SQL Server en SSIS naar Azure SQL en ADF is een periode van maanden waarin beide omgevingen gelijktijdig productie workloads draaien. Sommige pipelines zijn gemigreerd. Anderen niet. Sommige Power BI datasets refreshen nog steeds vanuit on-premise bronnen via de data gateway. Anderen zijn omgezet naar Azure.
De monitoring uitdaging is structureel: de meeste tools zijn gebouwd voor één van beide werelden. Azure Monitor dek je ADF-pipelines en Azure SQL. SQL Server Agent dek je SSIS-jobs. De ingebouwde monitoring van Power BI dekt je datasets maar toont je niet de upstream pipeline-status die een failure heeft veroorzaakt. Geen van deze tools geeft je een enkel overzicht van beide omgevingen tegelijkertijd.
Deze kloof produceert een voorspelbaar failure patroon. Een SSIS-package mislukt on-premise. De ADF-pipeline die hem had moeten vervangen is nog niet gedeployed. De Power BI refresh die afhankelijk is van die data draait, laadt verouderde data en rapporteert succes. Je ontdekt het wanneer een zakelijke gebruiker opmerkt dat de cijfers oud zijn. Op dat punt is de on-premise failure al uren geleden.
De data gateway is je grootste single point of failure tijdens migratie
De on-premise data gateway is de brug tussen je legacy on-premise systemen en Azure. Tijdens de migratie loopt vrijwel elke hybride Power BI dataset erdoorheen. Wanneer de gateway uitvalt, stoppen alle on-premise verbonden datasets gelijktijdig met refreshen, stilzwijgend, zonder fout, totdat het geplande verversingstijd aankomt en geen gateway beschikbaar vindt.
De gateway draait als een Windows-service. Hij heeft een bekende reeks failure-modes: service-crashes door geheugendruk, certificaat vervaldatum na 90 dagen (die de HTTPS-tunnel verbreekt zonder waarschuwing), netwerkbeleidswijzigingen die uitgaande verbindingen naar Azure blokkeren en Windows-updates die een herstart vereisen zonder de service automatisch te herstarten.
De gatewaystatus is pas zichtbaar in Power BI Service wanneer een vernieuwing daadwerkelijk mislukt. Proactieve monitoring vereist dat je de gatewaystatus rechtstreeks controleert op de machine waarop de gateway service draait. Dit is een eenvoudige HTTP-controle die de huidige status, de vervaldatum van het certificaat en de verbindingsstatus retourneert. Door deze controle elke vijf minuten uit te voeren, krijg je vroegtijdig een waarschuwing voor verlopen certificaten en worden service crashes gedetecteerd voordat ze geplande vernieuwingen beïnvloeden.
Clusters van gelijktijdige failures over alle on-premise verbonden datasets zijn bijna altijd een gateway-failure, geen individuele pipelineproblemen. Het lineagepatroon is de snelste indicator.
Het credential-oppervlak is het grootst precies wanneer je het drukst bent
Credential-beheer is de categorie die het meest waarschijnlijk een incident veroorzaakt tijdens migratie en het is degene die het meest waarschijnlijk wordt uitgesteld omdat het aanvoelt als een boekhoudingsprobleem in plaats van een engineeringprobleem.
Aan het begin van een migratieproject bestaan credentials op een klein aantal plaatsen: SSIS-package connection managers, SQL Server Agent-jobstappen en Power BI dataset-credentials in het adminportaal. In de loop van de migratie breidt het oppervlak aanzienlijk uit. Nieuwe ADF-linked services worden gemaakt voor elke gemigreerde pipeline. Azure Key Vault-referenties worden toegevoegd. Power BI dataset-credentials worden bijgewerkt om te wijzen naar Azure-endpoints. Sommige oude SSIS-packages draaien nog steeds on-premise en verwijzen naar de originele credentials.
Het failure patroon is voorspelbaar: een credential die prima werkte on-premise wordt bijgewerkt in Azure maar de on-premise referentie wordt niet opgeruimd. Of een Key Vault-secret wordt geroteerd als onderdeel van een beveiligingsbeleid en de ADF-linked service die ernaar verwijst wordt niet vernieuwd. Of een Power BI dataset-credential voor een gemigreerde bron verloopt omdat niemand het vernieuwingsschema heeft bijgewerkt voor het Azure-endpoint.
Migratie is het juiste moment om een enkele credential inventarisatie aan te maken, een lijst van elke verbindingsstring, serviceaccount en managed identity die een pipeline of dataset gebruikt, waar die is opgeslagen en wanneer die voor het laatste is gevalideerd. De inventaris hoeft niet geavanceerd te zijn. Een spreadsheet met de juiste kolommen voorkomt de klasse van incidenten waarbij een credential verloopt omdat die niet in iemands onderhoudsrotatie zat.
Schedule conflicten verbergen zich in het zicht
Vóór de migratie leefde het datalaadschema waarschijnlijk op één plek: SQL Server Agent-jobs. Het schema was eenvoudig te controleren.
Tijdens de migratie vermenigvuldigen schema's. SSIS-packages draaien vanuit SQL Server Agent. ADF-pipelines draaien vanuit ADF-triggers. Sommige Power BI refreshes zijn gepland in Power BI Service. Sommige worden programmatisch geactiveerd nadat een ADF-pipeline voltooit. De afhankelijkheden tussen deze schema's, SSIS draait eerst, dan pikt ADF de output op, dan refresht Power BI, zijn nergens centraal gedocumenteerd.
Schedule conflicten treden op wanneer twee componenten proberen dezelfde data tegelijkertijd te verwerken. Een ADF-pipeline triggert terwijl een SSIS-package nog schrijft naar dezelfde staging-tabel. Een Power BI refresh start terwijl ADF halverwege het kopiëren is naar de brontabel. De geladen data is partieel. De refresh slaagt. Het rapport is onjuist.
De meest betrouwbare manier om schedule conflicten te ontdekken is alle schema's samen te visualiseren voordat ze een incident veroorzaken. Een tijdlijn die SSIS-jobtijden, ADF-trigger tijden en Power BI refresh vensters toont, overlaid, maakt conflicten zichtbaar die onzichtbaar zijn wanneer elk afzonderlijk wordt bekeken. Deze audit duurt een middag en voorkomt de klasse van problemen die een dag kosten om te diagnosticeren.
Definieer wat gezond eruitziet in elke migratiefase voordat je het moet bewijzen
Migratiemonitoring moet voortgang bijhouden, niet alleen failures. In elke fase van de migratie maakt het expliciet definiëren van wat gezond eruitziet het mogelijk te verifiëren en geeft he je een verdedigbare baseline wanneer een zakelijke stakeholder vraagt of de migratie op schema ligt.
In de pre-migratie-baselinefase betekent gezond: alle on-premise pipelines draaien op schema, alle Power BI datasets refreshen succesvol, alle refresh duren binnen het normale bereik. Deze baseline is je referentiepunt voor vergelijking gedurende de migratie.
Tijdens parallel draaien betekent gezond: alle gemigreerde pipelines produceren output die overeenkomt met het on-premise equivalent binnen een gedefinieerde tolerantie. Rijtelaanpariteit tussen on-premise en Azure-pipelines voor hetzelfde tijdvenster is de meest betrouwbare check. Een gemigreerde ADF-pipeline die 48.000 rijen laadt terwijl het SSIS-equivalent 52.000 rijen laadt, verdient onderzoek voordat de SSIS-versie wordt buiten gebruik gesteld.
Bij de cutover betekent gezond: alle ADF-pipelines draaien op schema, alle Power BI datasets refreshen binnen verwachte vensters, gateway-gezondheid bevestigd voor eventuele resterende on-premise verbindingen en geen toename in refresh-foutpercentage vergeleken met de periode van parallel draaien.
Het definiëren van deze checkpoints vóór de start van de migratie maakt het mogelijk regressie vroeg te ontdekken in plaats van tijdens de eerste post-cutover maandag wanneer elke stakeholder toekijkt.