Azure Data Modeling and Migrations: Avoiding Painful Rewrites and Lessons Learned

[0:00]Andrey: Welcome back to the show! Today, we’re tackling a subject that’s both technical and surprisingly political: data modeling and migrations in Azure projects, and how to avoid the kind of painful rewrites that can stall a whole company’s roadmap.

[0:35]Andrey: I’m your host, Alex, and joining me is Priya Deshmukh, Principal Cloud Data Architect at Bluepeak Solutions. Priya, welcome to the show!

[1:00]Priya Deshmukh: Thanks, Alex! I’m really excited about this topic. Data modeling is one of those areas where early decisions echo for years, especially in the cloud.

[1:20]Andrey: Absolutely. Before we jump in, for listeners who might not know you—can you give us a quick background? What’s your day-to-day like at Bluepeak?

[1:40]Priya Deshmukh: Sure! I lead our cloud data architecture practice, which means I help clients design, migrate, and optimize their data platforms, mostly on Azure. I’m involved from initial scoping right through to production launches, so I see a lot of what works—and a lot of what doesn’t.

[2:10]Andrey: Love it. So let’s set the stage. Why do you think data modeling in Azure or any cloud is so much trickier than a traditional on-prem approach?

[2:35]Priya Deshmukh: In a word: change. Cloud platforms like Azure make it easy to scale, but they also make it easier to outgrow your original design—sometimes overnight. And with services like Cosmos DB or Azure SQL, the boundaries between compute and storage, or between transactional and analytical workloads, are blurrier than ever.

[3:05]Andrey: That’s a great point. I think a lot of teams assume the cloud will just handle complexity for them, when in reality, it exposes new failure modes.

[3:30]Priya Deshmukh: Exactly. Things like schema drift, inconsistent data across services, or hitting performance ceilings because of an inflexible data model—these challenges show up fast in Azure. The speed of delivery is a double-edged sword.

[4:00]Andrey: Let’s pause and define something. When we say 'painful rewrite', what does that actually look like in an Azure context?

[4:25]Priya Deshmukh: Great question. A painful rewrite is when your data model or migration plan is so mismatched with business reality that you have to re-architect, often under pressure. This could mean migrating millions of records again, rewriting APIs, or disrupting production systems. It’s expensive—in time, money, and team morale.

[5:00]Andrey: And these aren’t rare events. I’ve seen entire product launches delayed because the data model couldn’t support a new feature.

[5:20]Priya Deshmukh: Same here. One of the most common causes is underestimating how much a business will change after you ship. If your model is too rigid, every new requirement becomes a crisis.

[5:40]Andrey: Can you give us a sense of how those early modeling decisions ripple through a project?

[6:05]Priya Deshmukh: Absolutely. Let’s say you design your tables or collections for a very specific use case—maybe you denormalize heavily for speed, or you make everything relational for consistency. Fast-forward: marketing wants personalization, or a new region spins up, and suddenly your model can’t flex. The technical debt piles up fast.

[6:35]Andrey: So, it’s not just about performance today—it’s about adaptability tomorrow.

[6:45]Priya Deshmukh: Exactly. The cloud rewards flexibility. If your data model can’t evolve, neither can your product.

[7:10]Andrey: Let’s bring in a concrete example. Can you walk us through a time when an Azure SQL data model went off the rails?

[7:30]Priya Deshmukh: Sure. One client built a customer analytics platform on Azure SQL. They normalized everything—dozens of tables with strict foreign keys. Worked fine at first, but when they needed to add unstructured behavioral data, the joins killed performance. Eventually, we had to redesign large parts of the schema and migrate live data. It was months of work, all because the original model was too rigid.

[8:10]Andrey: That’s such a common pattern. I imagine the temptation is to just 'lift and shift' whatever you had on-prem into Azure and call it a day.

[8:35]Priya Deshmukh: Yes, and that’s a big trap. Lift-and-shift works for infrastructure, but data models need to adapt to cloud-native patterns. Azure gives you options—like partitioning, geo-replication, or different consistency levels—but you have to design for them.

[9:00]Andrey: Let’s define that for listeners: what’s the difference between a cloud-native migration and a lift-and-shift?

[9:25]Priya Deshmukh: Lift-and-shift means moving your databases as-is, maybe with minimal changes. Cloud-native migration means rethinking how your data is structured and accessed—taking advantage of Azure’s features, but also accounting for new constraints, like distributed consistency or scaling read/write workloads independently.

[9:55]Andrey: And I guess the hard part is knowing when to invest in that redesign, versus just getting it to work and iterating later.

[10:15]Priya Deshmukh: Exactly. There’s no one-size-fits-all. But I always tell teams: if you’re touching your data model anyway, take the time to model for the cloud, not just port what you had.

[10:40]Andrey: We’ve talked about failures—can you share another mini case study where data modeling for distributed workloads in Azure led to issues?

[11:05]Priya Deshmukh: Definitely. We worked with a fintech company that split data across Azure SQL and Cosmos DB. The initial model assumed all data would stay in one place, but as volumes grew, they needed to shard customer data by region. The codebase was tightly coupled to the old schema, so every new region meant weeks of coordinated changes. Eventually, they had to pause feature work just to re-architect for flexibility.

[11:45]Andrey: Ouch. So, what’s the lesson there—plan for distribution even if you don’t need it on day one?

[12:00]Priya Deshmukh: That’s one approach. At minimum, avoid hardcoding assumptions about where data lives. Azure gives you tools to abstract that—use them early, before scale forces your hand.

[12:20]Andrey: Let’s talk schema evolution. What are the biggest things teams get wrong here?

[12:40]Priya Deshmukh: A few things. One is assuming your schema won’t change much. Another is applying changes directly in production without testing. In Azure, schema changes can trigger re-indexing, cache invalidation, or even downtime if you’re not careful.

[13:05]Andrey: I’ve seen that—teams running 'ALTER TABLE' scripts at 2 a.m. and hoping for the best.

[13:20]Priya Deshmukh: Exactly! Or skipping versioning entirely. If you don’t track schema versions, you can’t roll back cleanly, and you risk breaking consumers downstream.

[13:45]Andrey: So, is there a best practice for managing schema evolution in Azure—say, for SQL versus a NoSQL service like Cosmos DB?

[14:10]Priya Deshmukh: For SQL, use migration frameworks, keep your scripts idempotent, and always test on a copy of production data. For Cosmos DB, be even more careful: schema is often implicit, so changes can break queries or indexing in subtle ways. Document your contracts and automate tests for new document shapes.

[14:40]Andrey: Are there anti-patterns you see over and over again?

[14:55]Priya Deshmukh: Absolutely. Tight coupling between services and data models is a big one—if you change the model, everything breaks. Premature optimization is another: designing for scale you may never need, which complicates migrations later.

[15:15]Andrey: Let’s unpack tight coupling—what does that look like in practice?

[15:35]Priya Deshmukh: Say you have microservices, but they all share one massive database schema. If you want to split out a service, you’re stuck. Or, every query is written directly against the database, so even minor schema tweaks ripple across the codebase.

[16:00]Andrey: And premature optimization? Is that like, over-sharding before you need to?

[16:15]Priya Deshmukh: Exactly. Or building in complex partitioning logic or caching layers before you’ve validated the business need. It’s better to start with a simple, well-understood model and evolve as usage patterns become clear.

[16:40]Andrey: I want to play devil’s advocate. Isn’t it risky to defer performance work until later—can’t that become technical debt?

[17:00]Priya Deshmukh: Good pushback. The nuance is: optimize where you have clear requirements, but don’t over-engineer. In Azure, scaling up is often easier than refactoring a tangled data model. But, yes, you need to plan for growth where you see it coming.

[17:30]Andrey: Let’s do another case study. Can you share a time when distributed data requirements were missed and it caused trouble?

[17:55]Priya Deshmukh: Sure thing. We helped an e-commerce client who started on Azure SQL, but later needed to support global catalogs. Their schema assumed a single currency and locale. When expansion came, every query and report needed refactoring. It took six months to unwind those assumptions and migrate data safely.

[18:30]Andrey: So, the takeaway is to challenge initial assumptions early—and build in some flexibility?

[18:45]Priya Deshmukh: Exactly. At the very least, isolate things that are likely to change—like currency, locale, or product attributes—so you can extend without rewriting everything.

[19:05]Andrey: Let’s talk about the business side. How do you balance the push for speed—get it shipped!—with the need for a flexible, future-proof data model?

[19:30]Priya Deshmukh: That’s the million-dollar question. My advice: timebox early modeling, but make sure you have a path to evolve. Use feature flags, keep migrations small and reversible, and communicate trade-offs with product managers. Sometimes you have to accept a little tech debt for speed, but it should be a conscious choice, not an accident.

[19:55]Andrey: Can you give an example of communicating that to business stakeholders?

[20:15]Priya Deshmukh: Sure. I’ll walk through the risks: 'We can deliver this feature fast, but if we don’t support multiple currencies now, future expansion will be harder. Here’s what it’d take to build in flexibility—do we want to invest now, or accept some risk?' That transparency builds trust and helps everyone make informed decisions.

[20:40]Andrey: Let’s pivot a bit. Incremental migration versus big bang—what’s your experience in Azure projects?

[21:00]Priya Deshmukh: Incremental all the way, if you can. Moving everything at once—big bang—almost always leads to surprises. In Azure, you can often dual-write to both old and new models, migrate subsets of data, and cut over gradually. It’s more complex operationally, but much safer.

[21:30]Andrey: Have you seen cases where incremental migration failed?

[21:45]Priya Deshmukh: Yes, sometimes teams underestimate the effort to keep two systems in sync. If you don’t automate validation and reconciliation, you can end up with data drift.

[22:10]Andrey: I want to zoom in on automation in migrations, but before we go there, let’s recap. So far: model for change, avoid tight coupling, communicate with business, and prefer incremental migration. Anything you’d add?

[22:30]Priya Deshmukh: Just one more: always have a rollback plan. Assume something will go wrong, and rehearse your recovery steps. In Azure, you can automate snapshots or backups—use them.

[22:55]Andrey: That’s a great transition. In the second half, we’ll dig into automation, rollback, and testing migrations in staging. But before we break, let’s reflect—what’s your biggest lesson learned from a migration that went sideways?

[23:20]Priya Deshmukh: The biggest? Never assume production data matches your expectations. We once migrated a billing system and discovered dozens of undocumented edge cases—legacy data, strange encodings, even missing values. We had to pause, rewrite parts of the migration, and revalidate everything. It was humbling.

[23:50]Andrey: That’s such a good point. Data in the wild is always messier than we think.

[24:00]Priya Deshmukh: Absolutely. Build in extra time for discovery and validation—it always pays off.

[24:15]Andrey: Alright, before we move on, I want to circle back to schema versioning. How do you manage that in a real Azure project?

[24:35]Priya Deshmukh: We use migration tools that track schema versions as code, and we keep a changelog in the repository. Every deployment tags the schema version, so we know exactly what’s in production. For NoSQL, we version document contracts and validate incoming data with tests.

[24:55]Andrey: And if you need to roll back—how painful is that?

[25:10]Priya Deshmukh: It can be tough if you don’t prepare. For SQL, we write down migrations as well as up, and test both. For document stores, it’s more about supporting multiple shapes in code until old data is migrated. The key is planning for rollback before you start.

[25:45]Andrey: Great advice. Let’s wrap up part one. We’ve covered why Azure data modeling is tricky, how early choices cascade, anti-patterns, and the importance of incremental migrations. Anything you want to leave listeners with before we jump into automation and testing?

[26:00]Priya Deshmukh: Just this: don’t go it alone. Involve both engineers and business folks early, and keep lines of communication open. The best migrations I’ve seen are collaborative from the start.

[26:20]Andrey: Perfect. When we come back, we’ll get into the weeds on automation, CI/CD, and making migrations boring—in a good way. Stay with us.

[26:30]Priya Deshmukh: Looking forward to it!

[27:00]Andrey: Alright, quick break, and we’ll pick it up with best practices for automating migrations in Azure.

[27:30]Andrey: Alright, picking up from where we left off, I want to get deeper into some of the real-world scenarios. We’ve talked about the basics, but let’s get into the weeds. Can you walk us through a migration project you’ve seen go off the rails? What actually happened?

[27:47]Priya Deshmukh: Absolutely. One comes to mind—a retail platform moving from a legacy on-prem SQL Server to Azure SQL Database. At first, the team underestimated how different the indexing and partitioning strategies needed to be in the cloud. They basically lifted their old schema as-is, assuming it would ‘just work’.

[28:05]Andrey: Oof, yeah. And I bet that caused some headaches.

[28:14]Priya Deshmukh: Big time. Within a couple months, performance tanked—especially during sales events. Their data access patterns had changed, but the model hadn’t adapted. It ended up requiring a mid-migration rewrite, which meant downtime and lots of unhappy users.

[28:35]Andrey: So, if someone’s listening and thinking about a move to Azure, what’s the first thing they should do to avoid that kind of pain?

[28:46]Priya Deshmukh: Honestly, map out your access patterns. Don’t just port your tables—think about what your workloads will actually look like in Azure. Are you batch processing, running OLTP, analytics, or real-time ops? Each might push you toward different data models or even different services.

[29:09]Andrey: Great advice. Now, let’s do a quick rapid-fire. I’ll throw out a scenario or misconception, and you give me a short answer. Sound good?

[29:13]Priya Deshmukh: Let’s do it.

[29:16]Andrey: First: 'It’s fine to use the same schema in Azure as on-prem.'

[29:21]Priya Deshmukh: False—always reassess for the cloud’s strengths and constraints.

[29:24]Andrey: Second: 'Lift-and-shift migrations save time in the long run.'

[29:28]Priya Deshmukh: Usually false—technical debt piles up fast.

[29:31]Andrey: Third: 'You can ignore partition keys in Cosmos DB until later.'

[29:35]Priya Deshmukh: Absolutely not—partitioning is fundamental from day one.

[29:39]Andrey: Fourth: 'Stored procedures are always portable to Azure.'

[29:43]Priya Deshmukh: Nope—many need rework, especially if you switch databases.

[29:46]Andrey: Fifth: 'Schema changes are easy to manage with microservices.'

[29:51]Priya Deshmukh: Careful—distributed systems make migrations trickier, not easier.

[29:54]Andrey: Sixth: 'Azure Data Factory takes care of all data migration logic.'

[29:59]Priya Deshmukh: It helps, but you still need to design transformations and handle edge cases yourself.

[30:03]Andrey: Love it. Okay, final one: 'Testing migrations on production data is safe.'

[30:07]Priya Deshmukh: That’s a recipe for disaster. Always test on sanitized, non-prod data first.

[30:13]Andrey: Perfect. Thanks for playing along. Now, you mentioned Cosmos DB earlier. Can we dig into that? What are some common modeling mistakes you see when teams move to Cosmos?

[30:27]Priya Deshmukh: Sure. The biggest is not thinking about partitioning and throughput from the start. Cosmos charges and scales by RU/s, so if you pick a poor partition key—like a static value—you end up with hot partitions and throttling.

[30:39]Andrey: Can you give an example of a good versus bad partition key?

[30:44]Priya Deshmukh: Definitely. Imagine you’re storing order data. If you partition by something like ‘country’, and 90% of orders are from one country, you’ll overwhelm that partition. Instead, something like ‘customerId’ or ‘orderId’—assuming they’re well-distributed—is much better.

[30:58]Andrey: And what about the cost side? How do modeling decisions impact your Azure bill?

[31:08]Priya Deshmukh: It’s huge. Over-normalizing can mean lots of cross-partition queries, which are expensive. Sometimes a more denormalized, document-style model is cheaper and faster. Design for the queries you’ll actually run, not just for the sake of 3NF.

[31:22]Andrey: So true. Let’s switch gears a bit. Tell me about a time a migration went surprisingly well. What made the difference?

[31:32]Priya Deshmukh: Yeah, there was this B2B SaaS provider moving millions of records to Azure SQL Managed Instance. They started with a pilot migration, built data validation scripts, and even involved business users to sign off on acceptance tests. That iterative, cross-team approach caught edge cases early.

[31:49]Andrey: I love that. So, involving stakeholders outside of engineering really mattered?

[31:56]Priya Deshmukh: Absolutely. They spotted issues the DBAs missed—like subtle data quality problems that would’ve broken downstream reports.

[32:04]Andrey: Let’s talk about automation. How much of this process should be automated, and where do you still need hands-on work?

[32:13]Priya Deshmukh: Great question. Automate repeatable steps—like schema deployment, migration scripts, and basic validation. But manual checks are still crucial for business logic, data anomalies, and user acceptance. It’s about balance.

[32:26]Andrey: Are there any tools or services in Azure that you find indispensable for migrations?

[32:35]Priya Deshmukh: Azure Database Migration Service is a big one—it helps with both schema and data transfer. Azure Data Factory is great for orchestrating complex ETL. And don’t overlook Azure Monitor for catching issues early.

[32:48]Andrey: Let’s dig into testing. What’s your go-to strategy for ensuring data integrity during a migration?

[32:57]Priya Deshmukh: I always recommend running parallel environments. Migrate a slice of data, compare row counts, checksums, and run business queries side-by-side. Automate as much as you can, but also eyeball the results. And don’t forget about downstream systems—test those too.

[33:13]Andrey: Can you share a quick story where that kind of testing saved the day?

[33:19]Priya Deshmukh: Sure. A fintech company was migrating their transaction history. Automated tests passed, but a business user noticed that certain legacy codes were missing. It turned out their transform step dropped a lookup table. Catching that before go-live saved them from a regulatory nightmare.

[33:35]Andrey: Wow, that’s a close call. Speaking of edge cases, what about schema drift—how do you deal with changes during or after migration?

[33:44]Priya Deshmukh: Schema drift is a killer. I recommend source-controlling your schema—use tools like Azure DevOps or GitHub Actions to track changes. And schedule regular schema reviews so nothing slips through the cracks.

[33:57]Andrey: Let’s get technical for a sec—how do you handle versioning with rolling migrations, especially in live systems?

[34:07]Priya Deshmukh: It’s all about backward compatibility. Start by deploying additive changes—new columns, tables, or endpoints—before removing or changing anything. Feature toggles help control rollout. And always have a rollback plan in case something breaks.

[34:21]Andrey: Have you ever had to rollback a data migration? How did that go?

[34:29]Priya Deshmukh: Unfortunately, yes. We hit a major bug in production and had to revert. Because we’d planned for it, we had database snapshots and a rollback script ready. It wasn’t fun, but having that safety net was a lifesaver.

[34:44]Andrey: Let’s talk about documentation. How important is it during migrations?

[34:52]Priya Deshmukh: It’s critical. Good documentation means anyone can pick up the process—even if someone leaves the team mid-project. Document data models, migration steps, validation rules, and known caveats. It also helps with audits and compliance.

[35:10]Andrey: I want to pivot to a mini case study. Can you share a story about a team that got data modeling right from the start—and what that looked like in the Azure context?

[35:20]Priya Deshmukh: Absolutely. There was a health-tech startup building a patient records platform. Early on, they brought in both engineers and clinicians to define critical access patterns. They used Cosmos DB, spent time modeling data to minimize cross-partition queries, and even simulated growth scenarios. The result: they scaled seamlessly and avoided performance bottlenecks.

[35:44]Andrey: That’s such a strong example of cross-functional collaboration. How did involving clinicians make a difference?

[35:52]Priya Deshmukh: They caught real-world requirements—like emergency access to records—that developers might have missed. That influenced both permissions design and partitioning strategy.

[36:01]Andrey: Let’s hit on some trade-offs. When would you choose Azure SQL over Cosmos DB, or vice versa, for a new project?

[36:12]Priya Deshmukh: If you need strong consistency, relational queries, and transactional guarantees, Azure SQL is your friend. If you have globally distributed workloads, need low-latency reads, or deal with flexible schemas, Cosmos DB shines. Sometimes, hybrid patterns—using both—make sense.

[36:28]Andrey: Speaking of hybrid, any gotchas when integrating multiple Azure data stores?

[36:39]Priya Deshmukh: Yes—data synchronization and consistency can get tricky. You need a clear strategy for eventual consistency, conflict resolution, and monitoring. Azure Data Factory can help orchestrate, but you have to design for failure and retries.

[36:54]Andrey: Let’s talk about security. What’s commonly overlooked during migrations?

[37:03]Priya Deshmukh: Least privilege is often ignored. Teams give broad access for convenience, but that opens risk. Use managed identities, encrypt data at rest and in transit, and audit access regularly. Also, don’t forget about data masking for sensitive fields.

[37:18]Andrey: How about performance tuning? Any tips specifically for Azure platforms?

[37:28]Priya Deshmukh: Leverage Azure’s built-in recommendations—like SQL Intelligent Insights or Cosmos DB’s query metrics. Monitor real workloads, adjust indexing strategies, and don’t be afraid to denormalize if it reduces costly joins or cross-partition queries.

[37:43]Andrey: What’s something people rarely think about but should before they migrate?

[37:51]Priya Deshmukh: Backups in the cloud. Azure makes it easy, but you have to configure retention, test restores, and make sure your backup strategy matches your RPO and RTO requirements. Don’t just assume the defaults are right for your use case.

[38:05]Andrey: Let’s go back to failed migrations for a minute. Any other anonymized case you can share—maybe something from the finance sector?

[38:15]Priya Deshmukh: Sure—there was a bank moving historical data into Azure Data Lake for analytics. They underestimated the need for data lineage and cataloging. Months later, analysts couldn’t trust the data because no one knew how it got there or if it was up-to-date. The fix was to implement Azure Purview for proper governance, but it set them back by weeks.

[38:39]Andrey: Wow, so the lesson is: never skip metadata and lineage.

[38:44]Priya Deshmukh: Exactly. If you can’t trace your data, you can’t trust it.

[38:51]Andrey: Alright, we’re getting close to our implementation checklist, but before we go there—what do you see as the future of data modeling in Azure? Any trends that excite you?

[39:03]Priya Deshmukh: I’m excited by serverless options—like Azure Synapse serverless SQL pools—and the rise of data mesh patterns. Also, AI-assisted schema recommendations are starting to help teams avoid classic mistakes. The tools keep getting smarter.

[39:18]Andrey: Do you think the fundamentals will change, or is it still about understanding your data and use cases?

[39:27]Priya Deshmukh: The basics never go out of style—know your data, know your workloads. But the tooling will keep raising the bar, so teams can focus more on business value and less on plumbing.

[39:39]Andrey: Alright, let’s move to our implementation checklist. For teams about to start a data modeling or migration project in Azure, what should be on their must-do list?

[39:51]Priya Deshmukh: Great—let’s structure this as bullet points. First: Map your workloads and access patterns. Second: Choose the right Azure data service—SQL, Cosmos, Data Lake, or a combination. Third: Design your schema for current and future needs, but keep it simple.

[40:09]Andrey: Fourth: Pilot your migration with a subset of data and users.

[40:15]Priya Deshmukh: Fifth: Automate schema deployment and data migration scripts. Sixth: Document every step—models, scripts, validation rules.

[40:29]Andrey: Seventh: Run comprehensive data validation—row counts, checksums, business queries, and downstream system checks.

[40:35]Priya Deshmukh: Eighth: Plan for rollbacks. Snapshot your databases and have a tested rollback script.

[40:41]Andrey: Ninth: Monitor performance and cost post-migration. Don’t set it and forget it.

[40:47]Priya Deshmukh: Tenth: Review security—least privilege, encryption, and audit trails.

[40:52]Andrey: And finally, involve stakeholders from Day One, not after it’s ‘done.’

[40:58]Priya Deshmukh: Exactly. If you follow those steps, you’re set up for a much smoother experience—and you’ll avoid those painful rewrites.

[41:09]Andrey: As we head into the home stretch, what’s one myth you’d love to bust about Azure data migrations?

[41:18]Priya Deshmukh: That it’s ‘just another lift-and-shift.’ Migrating to Azure is a chance to modernize—not just move stuff around. Rethink your models and processes.

[41:27]Andrey: If you could give one final piece of advice to listeners, what would it be?

[41:33]Priya Deshmukh: Don’t rush the planning phase. The more time you spend upfront understanding your data and defining requirements, the less cleanup you’ll need later.

[41:41]Andrey: Love that. Before we wrap, any quick resources or references you recommend for folks starting out?

[41:47]Priya Deshmukh: The official Azure Architecture Center has great reference patterns. Also, Microsoft Learn modules—especially for Cosmos and Data Factory—are really hands-on.

[41:55]Andrey: Alright, we’re almost out of time, but let’s do a lightning round. Just a word or two for each. Ready?

[41:58]Priya Deshmukh: Ready!

[42:01]Andrey: Best Azure tool for schema diffing?

[42:04]Priya Deshmukh: SQL Server Data Tools.

[42:07]Andrey: Favorite way to monitor migration progress?

[42:10]Priya Deshmukh: Azure Monitor dashboards.

[42:13]Andrey: One classic pitfall to avoid?

[42:16]Priya Deshmukh: Ignoring access pattern changes.

[42:19]Andrey: Preferred rollback strategy?

[42:22]Priya Deshmukh: Database snapshots.

[42:25]Andrey: Must-have documentation element?

[42:27]Priya Deshmukh: Migration runbook.

[42:30]Andrey: Best way to handle read-heavy workloads in Cosmos DB?

[42:34]Priya Deshmukh: Denormalize and optimize partition keys.

[42:37]Andrey: Most underrated Azure feature for data migration?

[42:41]Priya Deshmukh: Private endpoints for secure transfers.

[42:44]Andrey: Awesome! I think we covered a ton today.

[42:49]Priya Deshmukh: Yeah, this was fun—and hopefully super useful for anyone tackling migrations in Azure.

[42:55]Andrey: Before we officially close, let’s summarize with three key takeaways each. You go first.

[43:03]Priya Deshmukh: First: Model for your cloud workloads, not just your legacy system. Second: Test, validate, and document everything. Third: Prioritize stakeholder involvement and security.

[43:19]Andrey: And from me: Don’t skip pilot migrations. Automate what you can, but make sure to review results manually. And always plan for rollback—just in case.

[43:28]Priya Deshmukh: Couldn’t have said it better.

[43:33]Andrey: Alright, as promised, let’s wrap up with our final implementation checklist. I’ll read each step, and you tell me if you want to add or amend anything. Ready?

[43:36]Priya Deshmukh: Ready.

[43:39]Andrey: Step one: Analyze and document your access patterns.

[43:42]Priya Deshmukh: Spot on—include edge cases, too.

[43:45]Andrey: Step two: Choose the right Azure service and justify your choice.

[43:48]Priya Deshmukh: Yes, and review it with stakeholders.

[43:51]Andrey: Step three: Design your schema with scalability and partitioning in mind.

[43:54]Priya Deshmukh: Don’t forget about future-proofing for new features.

[43:57]Andrey: Step four: Build out test migrations and automate checks.

[44:00]Priya Deshmukh: Yes, and keep the test data up-to-date with production quirks.

[44:03]Andrey: Step five: Collaborate across engineering, business, and security teams.

[44:06]Priya Deshmukh: Absolutely. Early and often.

[44:09]Andrey: Step six: Document every schema and migration decision.

[44:12]Priya Deshmukh: And make sure docs are accessible to the whole team.

[44:15]Andrey: Step seven: Prepare and test your rollback plan.

[44:18]Priya Deshmukh: Practice it before you need it.

[44:21]Andrey: Step eight: Monitor cost, performance, and access post-migration.

[44:25]Priya Deshmukh: Don’t just set alerts—actively review them.

[44:28]Andrey: Step nine: Continuously review for schema drift and emerging needs.

[44:31]Priya Deshmukh: Yes, make it a regular sprint activity.

[44:34]Andrey: And finally: Celebrate the small wins along the way!

[44:38]Priya Deshmukh: Definitely. Migrations are tough—every step forward is worth acknowledging.

[44:43]Andrey: Alright, that’s a wrap for today’s episode. Huge thanks for sharing your expertise.

[44:47]Priya Deshmukh: Thanks for having me—it was a pleasure.

[44:52]Andrey: If you enjoyed the conversation, please subscribe, leave a review, and check out the show notes for links to resources we mentioned.

[44:59]Priya Deshmukh: And if you’re about to tackle a migration or redesign in Azure—good luck! Take your time, do the groundwork, and you’ll save yourself a world of pain.

[45:06]Andrey: We’ll be back soon with more conversations on building resilient, modern systems in the cloud.

[45:10]Priya Deshmukh: Take care, everyone!

[45:14]Andrey: This is Softaims, signing off until next time.

[55:00]Andrey: And for those who made it all the way to the end, here’s a quick bonus: If you want to dive deeper into data modeling in Azure, check out the Azure Architecture Center and Microsoft Learn modules. See you next time!