Most debates about cloud architecture focus on the wrong question. Teams argue over which database or identity provider is best for their workload. The better question is, how hard will this be to change in three years?
Teams treat certain foundational choices as technical decisions they can revisit later. It won’t be that simple. By the time you realize a choice has become permanent, changing it means rebuilding systems that already work.
In this edition, I’ll walk you through four decisions that fall into this category more often than teams expect.
Your database engine looks swappable
Database selection feels like a technical choice with room to adjust. Pick Cosmos DB for document flexibility or Azure SQL for relational workloads. If requirements shift in two years, migrate to something better suited. That’s the assumption.
How does it become permanent
The first application connects and runs fine. The second application shares the same database for convenience. By year three, a dozen services query the same tables, and each has built assumptions about schema, latency, and transaction behavior into its logic.
Microsoft’s Azure documentation warns that shared databases delay migration when multiple applications depend on them. Cross-server dependencies cause surprise outages when teams overlook them during moves.
IDC found that 60% of cloud buyers say their infrastructure needs major transformation, and 82% report their cloud environments need modernization. The straightforward migrations are done. What remains are databases with years of accumulated dependencies.
How to approach it
Treat database selection as a five-year commitment. Map application dependencies quarterly before they accumulate into surprises.
When choosing between engines, weigh the switching cost as heavily as the feature set.
Stay updated with Simform’s weekly insights.
Your identity provider feels like a configuration choice
Identity feels like infrastructure you set once and forget. Entra ID works. Okta works. Connect your applications, set up SSO for partners, and move on to problems that feel more urgent.
How does it become permanent
Every application you build inherits your identity provider. Partner integrations assume your current authentication model. Compliance certifications document the setup you already have in place.
The coupling deepens with age. Apps older than five years often require a complete rewrite to change providers. The business needs transitions to happen in weeks or months. A complete rewrite takes years.
Forrester Research says that 39% of organizations had to rewrite applications during identity migration, and nearly two-thirds described the process as highly complicated. Gartner introduced this accumulation as ‘IAM technical debt’. They define it as suboptimal identity decisions that reduce maintainability, slow development, and increase risk from badly managed tools.
Case in point
PwC‘s own identity transformation shows what accumulates over time. Before consolidation, they operated 13 IAM platforms and 90 Active Directory forests worldwide. 4,600 administrators managed identity for 350,000 internal users and roughly 2 million external users. Planning alone required a year of workshops across three continents before the actual migration could begin.
How to approach it
Assume your identity provider is permanent from day one. Audit how many applications inherit it annually. When evaluating providers, factor in the rewrite cost for your oldest systems.
Your AI embedding model looks like an implementation detail
Most teams building AI systems focus their energy on selecting the right large language model. The embedding model, the component that converts your documents into searchable vectors, gets far less attention. Pick one that works, generate your vectors, and move on to the more visible parts of the system.
How does it become permanent
Switching embedding models means starting over. Your existing vectors become useless. The new model produces vectors with different dimensions and represents meaning in an entirely different way. ada-002 outputs 1,536 dimensions. text-embedding-3-large outputs 3,072 dimensions. There is no conversion path between them.
So when a better model launches or your current model gets deprecated, you can’t simply upgrade. You have to reprocess every document in your corpus and rebuild your vector store from scratch.
For a company with a million documents, that’s a million reprocessing jobs. The AI knowledge base you build becomes the constraint you carry forward.
Gartner projects that 30% of enterprises will use vector databases by 2026, up from just 2% in 2023. These teams are making embedding model decisions today that will shape their AI capabilities for years.
How to approach it
Treat embedding model selection as seriously as database selection. Test retrieval quality across model versions before committing. Build reprocessing costs into your AI roadmap, because model changes will eventually force a complete rebuild of your knowledge base.
Your event architecture looks like a technical preference
When teams adopt event-driven patterns, the choice between Event Grid, Service Bus, or Kafka feels like a technical preference. Pick one that fits your current workload, wire up your services, and refactor later if your needs change.
How does it become permanent
Every microservice that publishes or subscribes to your event backbone builds assumptions into its code. Event schemas become contracts. Message ordering guarantees become requirements. Consumer retry logic assumes specific delivery behavior.
Research found that 68% of IT leaders plan to increase their use of event-driven architecture. But few organizations provide guidance on which brokers to use or how to manage event lifecycles.
Teams make these decisions locally, and by the time anyone notices the inconsistency, dozens of services have already committed to a specific pattern.
Once an API Gateway is entrenched, migration is complex, often unwanted, and sometimes doesn’t make sense.
The same logic applies to any integration infrastructure that touches dozens of systems.
Case in point
Visa migrated from BizTalk Server to Azure Logic Apps after years on their original integration platform. The move consolidated more than 100 systems and reduced infrastructure maintenance by 95%. But achieving that outcome required a significant investment to exit an architecture that had become deeply embedded in the company’s operations.
How to approach it
Treat event architecture as the integration backbone you’ll live with for a decade. Establish organization-wide standards before teams make local decisions. When evaluating messaging platforms, prioritize portability and schema governance over feature richness.
The fix is recognizing these decisions for what they are. Microsoft’s Well-Architected Framework now recommends Architecture Decision Records as a core deliverable for solution architects. The practice is simple. Document the decision, the context, and the alternatives you rejected. That record becomes your map of one-way doors.
If you want help identifying which choices in your environment have already become load-bearing, our architecture advisory team can walk you through them.
