I work at a bank that provides a platform-as-a-service environment for internal clients. We recently scaled the architecture significantly, which required replacing our monitoring system with a completely refactored design that I built largely on my own.
The new architecture is deployed and working, but the migration is still underway. I need to move alerts, products, dashboards, integrations, and other pieces from the old monitoring system to the new one. As I work through it, I keep uncovering operational issues, unexpected dependencies, and design decisions that need to change after deployment. Some components have already gone through 10 or 20 deployment iterations.
I understand the end goal, but I don't have a clear path for getting there. I am unsure whether I should migrate in layers, complete everything in one environment before moving on, or deploy broadly and make updates afterward. My backlog has become overwhelming, and it feels like the project will never actually be finished.
What methods do you use to break down and track a large technical migration with many unknowns? I'm especially interested in practical task-management approaches, planning techniques, or useful courses and resources.
3 Answers
Start by spending time planning before making more deployments. Define the target state, identify the major migration areas, and break each one into small deliverable slices. You will probably revise the plan as you learn more, and that is normal. The important part is making each change small enough to understand, deploy, verify, and roll back safely.
This is essentially project planning: keep breaking the problem down until each item is concrete enough to complete. For example, instead of tracking “migrate monitoring,” create tasks for one alert group, dashboard, integration, or product at a time. A ticketing tool such as Jira can help, but the tool matters less than having clear ownership, completion criteria, dependencies, and priorities.
Separate planned migration work from bugs and discoveries. Keep a prioritized migration backlog for the work that moves you toward the target state, and put newly discovered issues in a separate queue unless they block the current slice. Otherwise every unexpected problem makes the entire project feel unfinished. Notion can work for this too, as long as the lists and priorities stay current.
I agree with delivering in chunks. If every component was bootstrapped as part of one large effort, it may be worth stepping back and finding a sequence of independently useful migration slices instead of trying to finish the entire system at once.