Technology inventory

Kubernetes is modern and widely adopted. Adoption requires investment in learning and operations. Start with managed Kubernetes services to reduce infrastructure burden, and begin with non-critical workloads to build experience. Containerise applications before migrating to Kubernetes; the platform assumes containerised workloads. Consider whether your scale and requirements justify Kubernetes complexity, or whether simpler alternatives would serve you better.

Microservices is a modern but nuanced pattern. Migration from monoliths should be gradual: identify bounded contexts, extract services incrementally, and build operational capability over time. Don't migrate for its own sake; ensure you have the team size, deployment automation, and monitoring to support distributed systems. Many successful organisations use a mix of approaches, with microservices for areas that benefit and simpler architectures elsewhere.

GCP is modern and actively developed. Migration to GCP typically involves assessing which services match your needs, planning data migration, and gradually moving workloads. Google provides migration tools and programs to assist. Consider GCP alongside other cloud providers based on your technical requirements, existing skills, pricing models, and support needs. Multi-cloud strategies are increasingly common for avoiding vendor lock-in.

Architecture Review is an ongoing practice, not a migration target. Establish regular review cadences for critical systems, conduct reviews at key decision points, and build review capabilities within your team. Consider external reviewers for independent perspective or specialised expertise. Document findings and track remediation to demonstrate progress over time.

Technical Due Diligence is a service, not a technology. Engaging due diligence depends on your role: buyers and investors commission assessments, while targets prepare for them. If expecting due diligence, proactively address obvious issues, organise documentation, and ensure key technical staff are available. If commissioning due diligence, select assessors with relevant domain expertise and clearly define what decisions the assessment will inform.

Caching is a fundamental technique that remains essential. Improving caching typically involves analysing current patterns, identifying high-value caching opportunities, and implementing appropriate solutions (Redis, Memcached, CDNs, or built-in framework caching). Start with the biggest bottlenecks: often a few well-placed caches provide most of the benefit. Ensure you have strategies for cache invalidation and warming.

Performance Optimisation is an ongoing practice, not a one-time migration. Establish baselines by measuring current performance, set targets based on business needs and industry benchmarks, and implement changes incrementally. Focus on high-impact improvements first: often a small number of issues cause most of the problems. Build performance monitoring into your development process to catch regressions early.

API Integration is an essential skill, not a product to migrate to or from. Improving integration capabilities typically involves standardising approaches (using consistent authentication, error handling, and documentation), implementing proper monitoring, and building reusable integration components. Consider integration platforms (like Azure Logic Apps or Zapier) for common scenarios, and custom development for complex requirements.

Storyblok is modern and growing in adoption. Migration typically involves defining content models, importing existing content, and building front-end integrations. Storyblok provides migration tools and extensive documentation. Consider Storyblok when evaluating headless CMS options, particularly if the visual editing experience is important to your content team.

CQRS is a pattern, not a product, so adoption involves architectural decisions rather than tool installation. Start by identifying if your application genuinely benefits from the separation: complex queries, performance bottlenecks, or scaling challenges are good indicators. Implement incrementally, perhaps starting with a single bounded context. Be prepared for increased complexity in synchronising read and write models, and ensure your team understands the trade-offs.

Auth0 is modern and actively developed. Migration to Auth0 typically involves configuring the platform, integrating its SDKs, and migrating existing user accounts. Auth0 provides tools for bulk user import. Migration away is possible but requires careful planning around user credentials and session management. Consider Auth0 when building new applications or when existing authentication becomes a maintenance burden or security concern.

IoT is a broad, growing field rather than a single technology. Success depends on clear business objectives, appropriate technology choices, and realistic expectations about complexity. Start with pilot projects to prove value before scaling. Consider security from the beginning: IoT devices can be vulnerable, and breaches can have physical consequences. Build expertise gradually and leverage managed cloud services where possible.

MQTT is modern, with version 5.0 being current. Adoption involves setting up an MQTT broker (Mosquitto, EMQX, or cloud services like AWS IoT Core) and implementing clients on your devices. If using older MQTT versions, consider upgrading to 5.0 for improved features. Migration typically happens when standardising IoT communication or moving from custom protocols to industry standards.

Event-Driven Architecture is a modern pattern, not a specific product. Adoption requires choosing appropriate messaging infrastructure and designing events carefully. Start with clearly bounded use cases rather than trying to make everything event-driven at once. Consider the complexity trade-offs: EDA adds operational overhead and requires different debugging approaches. Success depends on good event design and clear ownership of event schemas.

Stripe Connect is modern and industry-leading. Migration to Connect typically happens when outgrowing simpler payment solutions or when entering marketplace territory. Existing Stripe users can add Connect capabilities incrementally. Migration away is rare and usually driven by specific regional requirements or pricing considerations. When evaluating, consider your geographic needs, expected transaction volumes, and the integration depth required.

Dapr is modern and growing in adoption. Introducing Dapr typically involves running it alongside existing services and gradually migrating functionality to use Dapr building blocks. Start with new services or well-bounded existing services to gain experience. The sidecar architecture means adoption is incremental: you don't need to change everything at once. Consider Dapr when standardising microservices patterns or planning for multi-cloud flexibility.

AI Integration is a rapidly evolving field. Success depends on clear objectives, quality data, and realistic expectations. Start with pilot projects that can demonstrate value quickly, and build internal expertise gradually. Be prepared for ongoing investment: AI capabilities improve rapidly, so today's integration may need updating as better options become available. Focus on architectures that allow components to be upgraded without rebuilding entire systems.

RAG is a modern pattern, not a product, so adoption involves choosing components: a vector database for storing document embeddings, an embedding model for converting text to vectors, and an AI model for generation. Cloud providers offer managed services that simplify implementation. Start with a well-defined use case and quality data; RAG is only as good as the documents it retrieves.

MCP is very new, released in late 2024. Adoption involves implementing MCP servers for your data sources and configuring AI clients to use them. The protocol is still evolving, so expect rapid improvements and expanding tool support. Early adopters should stay close to the specification and be prepared for updates. For organisations new to AI integration, MCP provides a more structured approach than ad-hoc solutions.

The C4 Model is modern and increasingly popular. Adoption typically involves agreeing on conventions with your team, choosing a diagramming tool (Structurizr, Mermaid, draw.io, or even whiteboards), and creating diagrams iteratively as systems evolve. There's no complex migration path; teams simply start using the approach for new documentation and gradually update existing diagrams when they become relevant.

Azure DevOps is modern and actively developed. Migration typically involves moving from older tools like Team Foundation Server (TFS), Jenkins, or fragmented toolchains. The platform provides import tools for migrating from TFS and supports gradual adoption, allowing teams to start with one service and expand over time. Consider Azure DevOps if consolidating development tools would improve visibility and reduce operational overhead.

RavenDB is modern, but less widely adopted than MongoDB or Cosmos DB. Migration may be considered if wider community support or cloud-hosted alternatives are preferred. Otherwise, it's a strong niche option for .NET-based projects.

Azure SQL is modern. Migration away is typically unnecessary unless an organisation is moving to a different cloud provider or wants to consolidate on an open-source stack. In such cases, databases like PostgreSQL or MySQL may be alternatives, but Azure SQL is a strong long-term option for Microsoft-focused businesses.

Cosmos DB is modern. Migration away would only occur if consolidating to a single database model or moving to another cloud provider. Its costs can be high, so organisations sometimes consider alternatives if budgets are constrained.

PHP remains current. Modernisation may involve upgrading to recent PHP versions, adopting a framework like Laravel for structure and security, and improving deployment (containers/CI). You'd move away only if consolidating stacks (e.g., standardising on .NET or Node) or if specific performance, language, or ecosystem needs are better met elsewhere.

EF Core (the modern version) is current and widely supported. Migration is only needed if you are on older versions of EF Framework (pre-Core), where moving to EF Core improves performance, cross-platform support, and long-term viability. Alternatives like Dapper may be chosen for lightweight scenarios, but EF remains a mainstream option for .NET apps.

WPF remains viable. Modernisation often means upgrading to the latest .NET (e.g., .NET 8) and improving deployment via MSIX or ClickOnce. Consider moving away only if your strategy shifts to cross-platform or web delivery; in that case, evaluate web apps (React/Vue) or cross-platform frameworks like .NET MAUI or Electron depending on requirements.

React is modern. Modernisation focuses on staying current with React versions, improving performance (code splitting, modern bundlers), and ensuring accessibility. You'd only move away if a simpler solution meets the need (e.g., a tiny widget) or if a team standardises on another framework for strategic reasons.

Docker is modern and foundational to cloud-native development. If not yet using containers, consider starting with Docker for local development before expanding to orchestration. Migration typically involves containerising existing applications incrementally.

Terraform is modern and widely adopted. Consider it if currently managing infrastructure manually or through provider-specific tools. Migration typically involves importing existing resources and gradually adopting IaC practices.

AKS is modern and actively developed. Migration considerations typically involve moving from self-managed Kubernetes or other cloud providers. AKS simplifies operations but requires understanding of Kubernetes concepts. For teams new to containers, consider starting with simpler Azure services before adopting AKS.

PostgreSQL is modern. Migration may be considered if organisational standards mandate another database, or if a simpler solution suffices. For most cases, PostgreSQL is a future-proof choice with growing adoption across industries.

MySQL is modern and reliable. Migration may be considered to alternatives like PostgreSQL if advanced SQL features, strict standards compliance, or licensing models become important. For cloud workloads, consider managed MySQL offerings to reduce operational effort.

SQL Server is actively maintained, but modernisation may be needed if you're on older versions. Migrating to Azure SQL (cloud-managed) or upgrading to the latest on-premises release reduces infrastructure overhead, increases performance, and improves security. Migration away entirely might be considered if licensing costs are high or if a cross-platform, open-source alternative better suits the organisation's needs.

MongoDB is modern. Migration might occur if strict relational guarantees are required or if an organisation wants to standardise on SQL databases. Otherwise, MongoDB continues to be a leading option for flexible, large-scale systems.

JavaScript itself is not outdated, but older styles of writing it can be. Modernising typically means adopting current language features, improving build pipelines, and introducing TypeScript for reliability at scale. Migration "away" only makes sense if your product's needs are purely native mobile or a platform where web tech isn't suitable.

TypeScript is modern and widely adopted. "Migration away" isn't generally necessary; instead, consider gradual adoption if you're currently on plain JavaScript, or streamline your type definitions if things feel heavy. The only reason to remove TypeScript would be a very small, quick script where formal types add overhead without benefits.

Vue itself is modern. If you're on Vue 2, consider upgrading to Vue 3 to benefit from performance, long-term support, and improved TypeScript integration. Migration "away" is rarely necessary unless organisational standards require a different framework; focus instead on keeping dependencies current and components well-structured.