Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Advice for leading a software migration?

news.ycombinator.com

Post reply on HN
Print view View original

71–80 of 80 posts

Re: Ask HN: Advice for leading a software migration?

#71

Post by jakozaur »

I co-founded a startup, Quesma, with one case to assist with database migrations. Big (e.g. move from tech X to Y) and small (schema change to add one column).

I did a fair amount of customer research and noticed almost all successful migrations have in common:

- they tested end-to-end migration, even on production data, early on

- very familiar with blue/green deployments or shadow testing

- gradual and have a good in-between story

- pragmatic (e.g. they moved 98%+ of data from SQL database to Cassandra but left some)

- very good revert story

- either simplified current system or split monolith into more manageable pieces

Many painful ones shared:

- wrote a next-gen system by a team that does not understand or has never worked on the current system

- big release day, after X quarters

- try to change too many things at once (e.g. database technology, schema, protocols)

- declared legacy system too early on, and everybody moved out of that development

- end up discovering flaws very late in the process

Re: Ask HN: Advice for leading a software migration?

#72

Post by sjf »

toast0 wrote: post #58
sjf wrote: post #23

Earlier quoted context omitted.

I support everything in this comment. After more than a decade at large sw companies, I can count on one hand the number of migrations where the legacy system was ever able to be turned down. I’ve seen migrations drag on for years, to the point where most of the team has turned over. I’ve seen them become a three-way migration because the second version was deemed insufficient so a third solution was introduced. Abso…

> After more than a decade at large sw companies, I can count on one hand the number of migrations where the legacy system was ever able to be turned down. If part of the plan wasn't to run a v1 shim on top of v2 to handle legacy users that won't migrate, v2 almost certainly doesn't meet the needs of v1 customers and it's not a question of 'migration' it's a question of ending a product and releasing a similar produc…

I’ve seen this happen in situations where the migration is totally invisible to users. My last team is five years into an opaque database migration that seems to only expand in scope. It’s just a symptom of the migration being more difficult than originally expected usually combined with losing momentum or leadership support. Obviously no one originally intends to keep maintaining both system indefinitely.

Re: Ask HN: Advice for leading a software migration?

#73

Post by smarri »

hoofhearted wrote: post #6
hoofhearted wrote: post #4

Follow the strangler fig pattern, and map out every single task that is required in the migration on a whiteboard. Write tests if you can, and set up a staging environment for V2 that you can setup and tear down easily for battle testing way before going live. From there, break the tasks up from above into their business domains, and abstract those into new api services that the v1 system can use without any downtime…

Original strangler fig post is here: https://martinfowler.com/bliki/StranglerFigApplication.html

I second this

Re: Ask HN: Advice for leading a software migration?

#74

Post by spikyman »

A very short list:

* The trick is to set everyone's expectations low, especially your own. E.g.; Even for a relatively small project, make sure management understands that there is no way to guarantee a schedule.

* If you think a step will take x days, schedule 4x days. EXPECT 4x. Generally, EXPECT bizarre failures to fry your so-called "schedule."

* Simple, obvious steps that work initially will suddenly stop working, and likely near the project's end.

* At least one thing not obviously connected to your project will stall everything (e.g., an old switch, a DB update, something somebody band-aided with COBOL 40 years ago**, ad nauseam.)

* You will almost certainly have at least one hair-pulling interaction with the security team. Hopefully, you'll have someone higher up to help you.

**yeah, that happened.

Re: Ask HN: Advice for leading a software migration?

#75

Post by leros »

One thing I've seen delay migrations is that people keep adding features to v1 during the migration because customers need improvements now. Then you have to add those changes to v2, which delays the migration, then more stuff gets added to v1 because the migration was delayed, etc. Ensuring that doesn't happen by setting the right expectations for stakeholders is important.

Re: Ask HN: Advice for leading a software migration?

#76

Post by trod123 »

Well it is hard to give advice when you don't really provide much regarding your background or your existing experience.

TPOSNA Volume 1/2 of Limoncelli has a lot of good wisdom in general for the operational side, though there are some aspects that have become dated, most has stood the test of time.

Re: Ask HN: Advice for leading a software migration?

#77

Post by philip1209 »

philip1209 wrote: post #9

I’ve done this. My quick thoughts: - migrations always run longer than expected. In my case, leadership estimates were off by a factor of 10. What the eng manager originally said would take 3 months ended up taking a couple years. - try to deliver quick wins and incremental value. This is often hard though. But it’s worth a try. - Try to avoid this becoming the project everybody attaches their pet projects too. It’s…

One delayed follow-up thought here:

Redesigns almost always result in a decrease in metrics/KPIs. The redesign just lacks the learned improvements that were baked into the old product. So, the initial launch almost always seems like a failure - and requires leadership to expect this dip before problems can be patched.

Re: Ask HN: Advice for leading a software migration?

#78

Post by drekipus »

philip1209 wrote: post #77
philip1209 wrote: post #9

I’ve done this. My quick thoughts: - migrations always run longer than expected. In my case, leadership estimates were off by a factor of 10. What the eng manager originally said would take 3 months ended up taking a couple years. - try to deliver quick wins and incremental value. This is often hard though. But it’s worth a try. - Try to avoid this becoming the project everybody attaches their pet projects too. It’s…

One delayed follow-up thought here: Redesigns almost always result in a decrease in metrics/KPIs. The redesign just lacks the learned improvements that were baked into the old product. So, the initial launch almost always seems like a failure - and requires leadership to expect this dip before problems can be patched.

Thanks for the follow up. I'm just making notes from this thread now and found that you only posted this 13 hours ago. :)

Re: Ask HN: Advice for leading a software migration?

#79

Post by drekipus »

jakozaur wrote: post #71

I co-founded a startup, Quesma, with one case to assist with database migrations. Big (e.g. move from tech X to Y) and small (schema change to add one column). I did a fair amount of customer research and noticed almost all successful migrations have in common: - they tested end-to-end migration, even on production data, early on - very familiar with blue/green deployments or shadow testing - gradual and have a good…

Thanks for this. I'm focusing on the top half :)

Re: Ask HN: Advice for leading a software migration?

#80

Post by drekipus »

withinboredom wrote: post #42

Everyone here has some good advice, but I didn't see this one listed: I work at a place that just finished the migration for ONE customer (of many) and it took about 2 years. The main issue we ran into was that NOBODY documented the difference in IDs between the old vs. new system. We had to Frankenstein that shit (look at original filenames of imported data to deduce what new id matched to which old id) which took M…

I'm almost in a similar situation, and I have to talk with the old team to discuss how they did it and what issues they faced.

the advice I'd recommend to you is to probably write down all your information so it's accessible by someone who needs it.

Post reply on HN