Zijn jullie een officiële Microsoft Partner?
Nee. We zijn een onafhankelijk bouwersbureau dat veel met Azure werkt, maar we presenteren ons niet als Microsoft Partner of Solutions Partner met een specifieke designatie. Voor sommige klanten is dat juist een voordeel: onze advisering kent geen kanaal-druk, geen partner-incentives en geen "deze service moeten we noemen omdat we partner zijn". Onze waarde zit in praktijkervaring met productie-werklasten op Azure — niet in een logo. Als u expliciet een partner-relatie nodig heeft, bijvoorbeeld voor een Microsoft-funded migratie-programma, zeggen we dat eerlijk en helpen we u de juiste partij vinden.
Werken jullie ook met AWS of Google Cloud?
Ja. We hebben praktijkervaring met alle drie de grote hyperscalers en zien geen reden om dogmatisch voor één te kiezen. Azure is vaak een sterke keuze voor organisaties die al diep in een Microsoft-stack zitten — Active Directory, Microsoft 365, Power Platform, Dynamics — omdat de identity- en data-integratie dan een logische voortzetting is. Voor organisaties zonder die voorgeschiedenis kan AWS of GCP net zo passend zijn. We adviseren ook waar een hybride of multi-cloud-opzet zinvol is — en waar het juist onnodige complexiteit toevoegt.
Hoe gaan jullie om met vendor-lock-in op Azure?
Bewust. Niet door alle managed services te vermijden — dat is vaak duurder in bouw- en beheerkosten dan de winst — maar door bij elke significante service-keuze de afhankelijkheid expliciet te benoemen. Voor sommige werklasten is een diepe Azure-integratie via Functions, Cosmos DB en Event Grid prima; voor andere is een container-aanpak op AKS verstandiger juist omdat die met beperkte aanpassingen op Kubernetes elders zou draaien. De afweging maken we per geval — geen verborgen afhankelijkheden die u jaren later overvallen.
Wat is een Azure Landing Zone en hebben we die nodig?
Een Azure Landing Zone (ALZ) is een gestandaardiseerde basis-inrichting volgens Microsofts Cloud Adoption Framework: een management-group-hiërarchie, een subscription-vending-aanpak, een hub-and-spoke netwerk-blauwdruk, baseline-policies via Azure Policy, een identity-laag in Entra ID en een gedocumenteerde aanpak voor logging en monitoring. Voor organisaties die structureel met Azure werken is het bijna altijd verstandig — een rommelig opgebouwde Azure-omgeving achteraf opnieuw structureren is veel duurder dan vooraf een goede landing zone neerzetten. Voor heel kleine organisaties met één Azure-subscription is een volledige ALZ overkill; dan adviseren we een lichtere baseline die later kan groeien.
Wat zijn de typische Azure-services waar jullie mee werken?
Compute: App Service, AKS, Container Apps en Azure Functions. Data: Azure SQL Database en Managed Instance, Cosmos DB, Azure Storage, Azure Cache for Redis. Edge: Azure Front Door en CDN. Identity: Entra ID voor medewerker-toegang, Entra External ID of Azure AD B2C voor klantgerichte authenticatie. AI: Azure OpenAI Service, Azure AI Foundry en Cognitive Services — zie ook onze
AI-ontwikkeling-pagina. Events: Event Grid, Service Bus en Logic Apps. Observability: Azure Monitor, Log Analytics en Application Insights. Dat is het hart; daar omheen werken we met talloze andere services als de situatie erom vraagt.
Waar slaan we data op — in welke Azure-regio?
Voor Nederlandse klanten meestal West Europe (Amsterdam); North Europe (Dublin) als secondary region voor disaster-recovery. Voor een Duitse focus kan Germany West Central (Frankfurt) een betere fit zijn, voor Scandinavische klanten Sweden Central. Wat regio-keuze niet automatisch oplost is data-lekkage via logging-, AI- of beheers-services die buiten de EU draaien. Daar speelt sinds 2024 de Microsoft EU Data Boundary een rol — een serieuze toezegging dat klant-data en diagnostiek binnen de EU blijven, maar geen vrijbrief om de configuratie niet te controleren. Dat moet apart worden ingericht via service-policies, juiste Key Vault-allocatie en bewuste keuzes rond cross-region-features. We doen die inrichting als onderdeel van een security-baseline.
Werken jullie met Azure DevOps of GitHub Actions?
Beide. Microsoft heeft Azure DevOps en GitHub onder hetzelfde dak; in de praktijk zien we GitHub Actions steeds vaker als de primaire CI/CD-tool, ook voor Azure-deployments — de developer-experience is sterker, de community groter en de Azure-integratie via de officiële actions is volwassen. Voor organisaties die historisch al diep in Azure DevOps zitten (work-items, repos, pipelines) is een migratie naar GitHub niet altijd zinvol; dan blijven we in Azure DevOps werken. Geen religie, wel een voorkeur voor toolkeuze die de developers van de klant comfortabel vinden.
Hoe verschillen jullie van een Azure-only consultancy?
Een Azure-only-partij kent het platform vaak tot in de hoeken — daar zijn ze sterk in. Wij zijn anders in drie opzichten. Ten eerste: we zijn vendor-onafhankelijk, dus de keuze voor Azure is een uitkomst van de analyse, niet het uitgangspunt. Ten tweede: we bouwen ook applicaties, niet alleen infrastructuur — wat de twee werelden in onze hand verbindt en handovers voorkomt. Ten derde: ons prijspunt past bij mid-market budgetten. Voor een organisatie die Azure al heeft gekozen en alleen platform-specifieke optimalisatie zoekt, kan een Azure-only-partij prima passen — voor wie advies en bouw verbonden wil houden, zitten we in een andere niche.
Wat bepaalt de kosten van een Azure-consulting-traject?
Vooral de scope en de complexiteit van de bestaande omgeving. Een Well-Architected review voor een kleine, overzichtelijke Azure-tenant is een ander traject dan een doorlichting van een multi-subscription-omgeving met tientallen werklasten, hub-and-spoke netwerken en complexe Entra ID-federaties. Daarnaast speelt de diepgang mee: een quick scan om de directie op weg te helpen is iets anders dan een uitgewerkt herstructurerings-voorstel. We werken met vast sprintbudget per fase, zodat u weet waar u aan toe bent, en breiden alleen uit als u zelf besluit door te gaan naar een volgende fase.
Werken jullie met onze interne cloud- of IT-afdeling?
Vrijwel altijd. We zoeken in de eerste fase actief contact met de cloud-engineers en security-officer om begrip te krijgen van wat er al loopt, welke beslissingen historisch zijn gemaakt en welke gevoeligheden er spelen. In de uitvoering werken we waar mogelijk met gemengde teams: uw mensen plus de onze, met duidelijke verdeling van eigenaarschap. Kennisoverdracht is geen sluitpost — als wij weggaan moet uw team de Azure-omgeving zelfstandig kunnen beheren en doorontwikkelen.
Hoe begint een traject concreet?
Met een kennismaking, vrijblijvend. We luisteren naar uw situatie en geven richting welke vorm — review, architectuur-ontwerp of begeleide implementatie — past. Voor een review krijgen we eerst lees-toegang tot de Azure-tenant zodat we het voorstel op feiten baseren, niet op aannames.