Thoughts/Feedback on a tool to help manage software migrations
Thinking of launching a tool to help software engineers/tech leads to manage software migrations. Imagine working in a team that is currently undergoing a long term migration in their codebase; for example migrating the codebase language from Java to Kotlin or changing the networking library. These changes usually happen over a span of a few months (or years) and require engineers to constantly make small changes. Without any specific tooling, it is difficult for engineers to understand how progress is going, what else needs to be done, who from the team is contributing to the migration etc.
This tool will solve this problem. It will integrate with Github, and after you set up a migration (by configuring the migration using a simple rule engine) it will constantly monitor the codebase and calculate the migration progress and who is moving the migration forward. It will then provide an informative dashboard, similar to the image above. The tool will also share important live updates to Slack/MS Teams about the progress of the migration.
This would definitely be useful if done right. People are gonna wanna know how it determines the progress. Is it just by files 'completed'? How do you know that ahead of time?
Hi @switchback, have you done migrations like these in the past in your own projects (personal or while working somewhere)? If so, can you provide some examples of migrations that you did, and possibly any mechanism that you used to track them?
Thanks for the feedback @switchback! For most migrations, the progress will be determined by files completed, yes. However, there might be migrations where progress can be measured by number lines. This can either be configurable by the user when they create the migration or something that is determined automatically based on the migration rules.
The system will be able to estimate the completion time based on previous data. So at the start of the migration, the estimated completion date will not be available. But as engineers start contributing to the migration, the system will use the previous migration velocity to estimate how long it will take to migrate the remaining files.
Gotcha. To answer @athkalia's question, I have done big (4+ months) code migrations for my own projects and at work. But lines/files would've been a very flawed way to track those projects. Migrations aren't as linear or simplistic as that. Half the days I only focused on a few lines and wondered why the heck it's not doing what I thought it should. Others, I cruise through the migration effortlessly.
So, for an engineer who is getting their hands dirty , I don't think it's that helpful. But perhaps for other engineers or stakeholders who aren't directly involved it could be an OK approximation.
Thanks for the information! Do you have any examples of migrations that you have done that you could share?
They were for another company, so I unfortunately don't have anything to share
No worries, thanks anyway! :)