I work at a bank that provides an internal PaaS, and we recently scaled the architecture significantly. As a result, our monitoring system needed a near-total redesign, which I have largely handled myself.
The new architecture is now deployed and functioning, but the migration is still underway. I need to move alerts, products, dashboards, integrations, and other pieces from the legacy monitoring system to the new one. During day-to-day operations, I keep finding unexpected problems, delayed alarms, missing requirements, and design decisions that need to change when they interact with other components.
I have already gone through roughly 10–20 deployment iterations, and the backlog is now overwhelming. I understand the overall goal, but I do not have a clear path for reaching it. I am unsure whether to migrate in layers, deploy everything in one environment first, or roll out and update each part incrementally.
How do you organize and manage a project this large? I would appreciate practical advice, recommended tools, or courses focused on breaking down complex technical work and keeping the task backlog manageable.
3 Answers
Start by stopping and planning the migration as a series of small, deliverable slices. Break the work down until each item is concrete enough to complete and verify on its own. You will probably revise the plan as you learn more, and that is normal. For every change, define how you will test it and how you can roll back if something goes wrong. A staged rollout is usually safer than trying to switch every component at once.
This is essentially project planning: take the overall problem and keep decomposing it into smaller tasks until you reach work that can realistically be completed in a day or a few days. Track those items in a tool such as Jira, Notion, or another project board, and give each one a clear definition of done. Keep a separate backlog for bugs, discoveries, and future improvements so every new issue does not make the primary migration feel like it has failed.
I would organize the migration around small slices, such as moving one product or alert group at a time. Validate each slice in a lower-risk environment, monitor it for a while, then continue with the next one. Keep operational bugs and newly discovered requirements in a separate queue, prioritize them regularly, and avoid constantly interrupting the current migration step unless the issue is genuinely blocking or dangerous. A simple board in Notion can be enough as long as it shows what is planned, active, blocked, and finished.
I am currently using Notion, so separating the migration work from bugs and discoveries sounds like a practical place to start.
Exactly. If every component was bootstrapped as part of one large delivery, it may be worth reorganizing the work around smaller outcomes instead of treating the whole platform as a single release.