Happy New BLOG!! What We Got Right (and Wrong) – Lessons from Nevermore’s ALM Journey

So far in this blog series, we’ve taken you deep into Nevermore Technology’s Power Platform landscape—five Dynamics 365 instances, twenty environments, a flood of apps, integrations, pipelines, security policies, and enough solution layers to start a new religion.

But let’s be clear: they didn’t get it all perfect from the start.

In this post, we’re pausing to reflect. Because real ALM success doesn’t come from reading a Microsoft doc and following it to the letter—it comes from experimentation, iteration, and a fair bit of troubleshooting.

Here’s what Nevermore got right… and what they wish they’d known earlier.

✅ What Went Well

1. Starting with a Proper Environment Strategy

They didn’t use the Default environment for anything meaningful. From the beginning, Dev/Test/Pre-Prod/Prod were set up per instance, with access policies, naming conventions, and security boundaries.

That single decision saved them from an unholy mess of unmanaged apps, rogue makers, and confusing environment logs.

2. Using Solutions from Day One

They didn’t faff about with exporting single apps or flows. Every component lived inside a solution, even if it was just one lonely canvas app. This meant pipelines were possible, upgrades were clean, and documentation stayed consistent.

3. Building a Core Layer Early

The idea of a Core-Data solution seemed over-engineered at first, but once they had 15 model-driven apps referencing the same 4 tables, it became the glue holding everything together.

Same with shared plugins, flows, and connection references—they were centralised from the get-go.

4. Pairing Makers and Pro Devs

Nevermore deliberately fostered mixed teams—makers and devs working together in Dev environments, sharing knowledge. It reduced friction, improved quality, and gave everyone a better appreciation of governance.

Bonus: citizen devs learned Git. Mostly.

❌ What They’d Do Differently

1. They Waited Too Long to Tackle Solution Layering

In the early days, a few too many “quick fixes” led to unmanaged customisations slipping into Test and Pre-Prod. They had to use the Solution Layer Viewer to manually clean things up.

Lesson learned: enforce managed-only outside of Dev as early as possible.

2. Didn’t Standardise App Ownership Early

For a while, they had canvas apps owned by departed employees, flows with no assigned owner, and plugins built by contractors with no documentation.

Now they use a centralised App Registry, and nothing goes live without an owner assigned for both business and technical support.

3. Underestimated Connection References

At first, flows were built with direct connections—no environment variables, no connection reference configs. That led to lots of broken flows in Test/Pre-Prod when the credentials changed or connectors weren’t present.

They now wrap every integration in a DeploymentResources solution, with variables per environment and connectors clearly managed.

4. Tried to Run ALM Without a Centre of Excellence

They waited until Instance 3 to fully adopt the CoE Starter Kit, and… it showed. Before that, they lacked visibility into who was building what, where, or why. Pipelines helped, but CoE analytics brought everything together.

Now, everything feeds into Power BI dashboards that make governance feel less like guesswork.

⚠️ What They’re Still Working On

• Automated Testing: They’ve got a few smoke tests in place using EasyRepro, but want broader test coverage across canvas apps and flows.
• Change Request Process: App changes still rely on too many Teams messages and spreadsheets. A unified ALM backlog is being trialled using Azure DevOps boards.
• More Git Discipline: Let’s just say not everyone’s a fan of branches yet. Some team members are still committing directly to main. Progress, not perfection.

🧠 Top Advice for Anyone Starting Their ALM Journey

1. Start small, but start properly. Even a two-environment setup can benefit from solutions and pipelines.
2. Make documentation a deliverable, not an afterthought.
3. Expect to rebuild some of your assumptions. What worked for one app may not scale.
4. Own your mess-ups. ALM is about continuous improvement. You won’t get it perfect first time.
5. Talk to your makers. ALM is not something done to them—they’re part of the process.

TL;DR – There Is No “Done” in ALM

ALM isn’t a switch you flip. It’s a framework you grow into. It evolves with your business, your platform maturity, and your people.

Nevermore’s ALM journey isn’t finished—because it never will be. But they’re a lot more stable, scalable, and future-proof than they were at the start.

And really, that’s the goal.

Coming Up: Blog 12 – The Future of ALM at Nevermore

In our final post, we’ll look ahead: where Nevermore is taking their ALM strategy next, what new tools or practices they’re experimenting with, and how they plan to scale even further—without going backwards.

Sneak peek: AI, Co-Pilot, and self-healing pipelines are all on the roadmap.