I've been spending time this week, refactoring our Azure DevOps tenant. We have been using Azure DevOps at my company for as long as I can remember (well over 10 years?), and over time we've used it in different ways. We never had good governance, but would create projects and teams within projects as they come up.
For the past several years, we've had one main project in Azure DevOps where we would create a team within the project for each of our actual projects. This allowed us to roll-up all our tasks to the main board, but resulted in us being locked into a single process type, iterations, and more.
We would also have separate projects created for each repository we needed.
I'm working on breaking away from the consolidated team and using DevOps how I think it was intended. One project per client. Within that project, we'll have teams for each major initiative (most projects only have one). All the repositories for that client are within that same project.
This approach allows us to more easily manage team members, permissions, and each project can have its process. In other words, our simple projects can have a simple To Do, Doing, Done type approach, while our bigger projects can have additional states that give us more control.
The separate projects will make it easier to have a single Wiki per client, as well as dashboards, control over sprints (when we use them), and much more.
Overall, it's pretty easy to move tasks around. Create a query, select the tasks I want to move, right-click and move to project. But it does get tedious. I'm excited for it being done. Maybe a weekend project?