Blog

Why I wanted to do a recap

Over the last couple of months, I have published a steady mix of posts across Microsoft 365 security, identity, migration planning, Power Platform solution design, Dynamics 365 integration, Azure-based builds, and AI readiness. Looking back across them, what stands out most is not just the variety of topics, but the consistency of the underlying approach: practical architecture, operational reality, and repeatable patterns matter more than buzzwords or clean diagrams.

A lot of the recent writing has been grounded in the same kinds of questions I see repeatedly in real-world environments: How do you strengthen security without breaking the business? How do you modernize identity and endpoint management without overcomplicating deployment? How do you turn scattered manual work into structured, supportable processes? And how do you adopt newer capabilities like Copilot and AI in a way that actually aligns with governance, cost control, and business value?

What this stretch of writing was really about

Security and governance stayed at the center

One of the strongest themes in recent posts has been security, especially where security intersects with day-to-day operations. In Modern Microsoft 365 Security Baseline Bundle for SMB / Mid-Market, I laid out a layered baseline across identity, endpoint security, email and collaboration protection, data protection, privileged access, and operational visibility. The emphasis was not on checking every feature box, but on connecting controls in a way that is practical and enforceable.

That same thinking carried into Windows Hello for Business in Hybrid and Cloud-Native Environments, where the focus was on passwordless strategy, Cloud Kerberos Trust, and how modern authentication can bridge cloud identity with legacy on-premises dependencies. I also spent time digging into controlled application control rollout in App Control for Business in Practice: From RMM and Security Tool Validation to Autopilot Pre-Provisioning Enforcement, because successful enforcement work always depends on validation, sequencing, and understanding what really runs in production.

Governance-focused posts reinforced the same operational theme from a different angle. In SharePoint Permissions in 2026: Safer Alternatives to Default Members = Edit, the goal was to show a more modern, supported approach to reducing over-permissioning risk. In Enable Microsoft Message Encryption (MME) & IRM — Why Older Tenants Must Verify This, I highlighted one of those foundational tenant-side issues that can quietly undermine expected compliance behavior if it is never validated.

Migrations and modernization remained deeply practical

Another major theme in recent posts was migration and modernization work. In Setting Up Migration Tools for Microsoft 365 Tenant Moves, I focused on the setup path for tools like Movebot and BitTitan and the repeatable preparation steps that make migrations more predictable. That topic paired naturally with The Hidden Complexity of “Simple” Microsoft 365 Migrations, which reflects something I see constantly in the field: two projects can look similar at a high level and still behave very differently once identity, device state, licensing, or user workflows enter the picture.

Collaboration migration also surfaced as an important design topic in Teams Migration Strategy for M&A: Rebuilding Google Spaces into Teams Channels. The big takeaway there is that collaboration architecture should never be treated as an afterthought to mailbox or file migration. Rebuilding communication patterns inside Microsoft Teams requires ownership, structure, lifecycle thinking, and often a willingness to retire noise instead of recreating everything exactly as it was before.

I also spent time framing modernization through assessment and planning work in What an IT Assessment and Roadmap Can Reveal. That piece centered on how assessments can uncover hidden continuity risk, inconsistent management, documentation gaps, and fragmented tooling—then translate those findings into an actionable modernization sequence. In a similar vein, Choosing the Right Cloud Platform for a Repeatable SMB App explored the tradeoffs between Microsoft, AWS, and GCP approaches for reusable business application patterns.

Power Platform content focused on real workflows, not demos

A big portion of the last 60 days was also dedicated to Power Platform and Microsoft 365-based solution design. Some of that content was foundational, such as Getting Started with Power Apps: Building Your First Canvas App and Getting Started with Power Automate — A Practical Guide. Those posts were meant to create a usable entry point for people looking to move from interest into hands-on development.

But a lot of the more interesting work lived in the applied solution posts. In Building a Power Apps Onboarding Solution with Power Automate, I walked through a structured onboarding pattern using Power Apps, SharePoint, approvals, downstream automation, notifications, task creation, and operational follow-up. In Building a Vendor Management Portal with Power Platform, the theme was building a centralized, lightweight, CRM-style experience around structured vendor data and automation.

Similar patterns carried into Building a Customer Research Workflow with Power Automate and Microsoft 365 and Automating Finance Document Processing with Microsoft 365, where the focus was on intake, document generation, workflow orchestration, task assignment, and lifecycle control. Those are good examples of how much value can be delivered when Microsoft 365 tools are treated as a connected platform instead of isolated apps.

I also wrote about more specialized and personal build patterns in Building a Metal Trade-In Pricing App with Power Apps and Building a Data-Driven Vinyl Collection App with Power Apps. Even though those solutions targeted very different use cases, the patterns underneath them were very familiar: structured data, filtering, dynamic calculations, user-guided workflows, and automation filling the gaps where the native platform needs a little help.

AI and Copilot were framed through adoption, cost, and readiness

AI-related content showed up in a more strategic and grounded way than the broader market conversation usually allows. In Copilot Pay-As-You-Go — A Smarter Way to Start Your AI Journey, I focused on a consumption-based adoption model that enables pilot usage, controlled spending, and real-world validation before large-scale licensing decisions. That post was less about feature excitement and more about how organizations can start carefully without guessing at value.

I also wrote From Fundamentals to Transformation: My Journey Through Microsoft AI Certifications (AB-900, AB-730, AB-731), which reflected on building AI knowledge across fundamentals, business value, and organizational transformation. What mattered most in that journey was not just passing exams. It was developing a more structured way to think about responsible adoption, change management, real use cases, and how AI should support the modern workplace rather than distract from it.

That perspective connects directly back to the broader security and governance content as well. AI is valuable, but only when identity, permissions, access boundaries, and information handling are already in a healthy state. The better the underlying Microsoft 365 environment is designed, the more confidently organizations can adopt capabilities like Copilot.

Build stories and integration work added an engineering lens

Another part of the recent blog stretch that I especially enjoyed was the more hands-on engineering and build-story content. In Building a Serverless Data Dashboard with Azure Functions and SharePoint, I documented how a working cloud application came together over a few focused weekends through structured data, serverless APIs, identity engineering, and staged frontend progress.

That thread also ties into Building a Modern Static Web App — Weekend 3 (Frontend MVP), where the focus narrowed to the transition from backend capability into a usable product surface. Those posts are a reminder that the code itself is often only one part of the project. Identity, permissions, deployment behavior, hosting, and end-user experience often create the real complexity.

On the business application side, I also explored how Microsoft services fit together across systems in Streamlining Document Collaboration in Dynamics 365 with Microsoft Teams and Connecting a Chatbot to Dynamics 365 via API — Dataverse Access Setup. Both posts focused on practical integration patterns: where collaboration should live, how secure access should be provisioned, and what needs to be in place before a broader workflow or automation layer can succeed.

Selected reading from the last 60 days

Closing thoughts

One of the things I appreciate most about writing regularly is that it creates a record not just of technologies, but of patterns and priorities. Looking back at this recent stretch, I see a body of work shaped by secure design, process clarity, practical solution architecture, and a strong bias toward making modern Microsoft tools usable in the real world.

If you have been reading along, sharing posts, or reaching out with thoughts and questions, thank you. I am looking forward to continuing the conversation around Microsoft 365 security, Power Platform development, AI readiness, migration planning, cloud architecture, and the operational decisions that make these platforms succeed.