31–40 of 80 posts
Assuming V1 and V2 offer users the same functionality, there’s a bunch of tests you can offer. The best one IMO is oracle testing where you do something on v1 and v2 and check they do the same thing. Preferably roll out to a subset of users such as via a canary deployment and make sure you have a rollback plan.
It's not clear whether v2 is already in production somewhere else. If it is not, you better wait until 1) the v2 data model has really been finalized and in prod and 2) key resources can be made available to the migration team. We were forced to begin the migration before the new product was complete and it was just plain impossible. We had to start all over every quarter.
- Migrations are very difficult to estimate. Any optimistic estimate will bite back. Hold off as much as you can, and ensure appropriate buffers if you really have to.
- ensure that the 8 clients have an identical v1 data model (tables, constraints, etc). If that is not the case, remember you will run n migrations, not 1.
- You need a team with knowledge of both v1 and v2 data models, as well as business domain know-how. There are many decisions that need to be made and you need the right people to be around.
- Not everything has to be migrated. Trying to migrate 100% is a common mistake: engage with the customers to understand what's the minimum that legally and operationally has to be migrated, especially if the v1 system has been in production for many years.
- Data migration is a iterative process, and the last thing you want to is to manually QA every iteration. You need to develop tests that will provide a reasonable data integrity assurance.
- Dashboards showing data migrated, failing/ok tests, remaining tables, etc. help communicate status and track progress.
- Customers will need to be involved during the whole project. You need them to commit to making people available that can quickly answer questions to unlock you dev teams. ideally, you want to create a single team. Make sure that decisions are traced and versioned.
- Performance matters. Discuss the performance requirements upfront. Our process was very, very slow and we found out a bit too late that the customer would not tolerate such down time. Also, discuss "when" ok to migrate, how to rollback in case of failure, etc.
Try to automate what you can, efficiently. Code conversion, tests, etc.
Keep an eye out for opportunities to simplify things.
Make sure to have buffer built into your time/effort estimations.
Ask lots of questions.
Find other folks who interact with different parts of the system and ask if some of their time can be allocated to the conversion.
If you can onboard other folks, find out if there's anything you can do to automate any of their work.
What is motivating the move technically? What is motivating the move politically? What is motivating the move psychologically? Be clear regarding each. They are all there in the decision. Don't pretend they aren't. Only one of them is technical. And it is not most of success. Good luck.
This. Even though you/we are [mostly] focusing on the tech aspect of the world, make no mistake; the “business side” (or the political) can kill your migration project more suddenly and decidedly than you can spell ‘strangler pattern’. So, to add to the comment above: - does your migration affect the clients and the way clients work in any way? No matter how small, if the answer is “yes” then you need to ensure full…
Technical and political components are external. Career aspirations and mitigating boredom/stagnation by pursuing complicated work create motivations to invent interesting projects.
And there’s the ability to claim integration from v1 to v2 as progress. Rather than only change.
To put it another way there is always some degree of change for the sake of change motivating our desires for change. Particularly when a big chunk of our time must be accounted for. Typically, playing video games, sleeping, and walking a dog through the woods instead are not viable alternatives in contexts where data migrations are being considered.
If migration was something the OP didn’t want to do, the question would be about finding a new job.
I mined HN last year for all migrations. You can filter by various fields like technologies etc. The table will probably be most useful since it links off to the blog posts etc
1. Don't - i don't know the size of the software but for us it was lots of works specially at weekends and holidays. after release almost half of the developers quits and the other half were exhausted. totally doesn't worth that.
2. Don't - if its possible to fix and refactor current version please do that. you would thank yourself later. we had 15 months of developments and in the middle of the project we need some features and fundemental fixes for our current version which we ended up another minor migration that we called v2.9.
3. Don't - only do it if you had to and do it incrementally as others suggested. start by building a microservice for most used domain of your application with api backward compatibility (if possible) and even use same database you are already using.
If you can't refactor current version (which i can't understand why) and you insist to have a bigbang migration know the current system well and know every column in the database(s) since you will need to migrate millions of data at the end which is a big project by itself.
If people are pushing for changes to the app to better match how the business works today, leap into that conversation, but don't get talked into changing the app. Instead aim at reworking their business processes to first make their process as simple as possible, and then simplify the app to match the new process. Your migration is simpler when their process is simpler, and everyone wins.
If people aren't willing to refactor business processes as part of the effort, then refuse to change requirements. Hold steady to "We both improve, or we stick to the status quo."