So You’ve Decided to Do a Technical Migration

It seems like there’s always a hot new library or framework promising great things. But people often forget about the pain and effort required to move from an old technology to a new one. How long will it take? If you finish, will it be worth it? And if you don’t, could it leave you in a worse place than where you started?

Drawing from her experience of the Typescript migration they recently completed at Monzo she’ll take you through some of the different outcomes of technical migrations and the things they learned along the way.

Transcription

(Music Playing) (Applause) Thank you.

Thank you very much. It is so exciting to be back here at BT. I haven’t been to this Berlin one before, but it’s an absolute delight. It’s been a great morning already, and I’m excited to talk to you and share my stories. So many of you in this room will have gone through a technical migration at some point in your careers. And if you haven’t, you might have migrated from one piece of software to another, even migrated your files from Google Drive to Dropbox, anything like that. It all counts. The important thing is that if you’ve ever struggled with a migration, I’m here to tell you that you’re not alone, because migrations are really hard.

And it’s really easy to start out thinking that it’s going to be a straight line to the end where everything is going to be better right away on the new system. But in reality, of course, it’s often a lot more like this, an uphill path full of twists and turns and surprises,

unforeseen hiccups, bends in the road, interruptions that take away your focus, and what looks like a seemingly short distance that actually takes a lot longer to cover than you might think. So I’m going to talk to you about the bends in the road that we face, embarking on a big technical migration at Monzo where I work, how we navigated those bends in the road, and some of the lessons that we learned along the way.

And I’m going to talk to you about how to know whether you should be doing a technical migration at all.

So my name is Sophie. I’m a senior engineer and the web discipline leader at Monzo, which is a bank based in London.

And my role as web discipline lead means I’m kind of accountable for the general direction of the web and the technologies that we use at Monzo. I’ve got a website. Occasionally write about tech things, mostly just write rubbish. But you can find me in various places around the internet as well.

Now, Monzo is a bank that lives on your phone,

makes managing your money super easy, so we hope. We’re very big in the UK, known for our very brightly colored cards. And we’re also growing in the US. And we have plans to expand in the EU very soon, so watch the space.

And as an app based bank, our main product is just that. It’s a mobile phone app. But we do have web things as well. So we have a website. Most companies do these days.

And this is where you can see product information and help articles.

We’ve also got a web banking app for our business customers, where you can do things like view your transactions, manage your money, make payments, all of the things that you might want to do with a bank.

But the largest app by far is our internal tooling. And this is what I work on. It’s called BizOps. And it’s used for our customer service. So anything like chat calls, emails, anything that you might need to help a customer with a problem. And it all goes through this app. So as you can imagine, it’s very complex indeed.

And we recently migrated our web properties to TypeScript. And it took a really long time. This is actually the sticker that we got made after we finished.

It actually took us just over two years. But it did come out pretty well in the end. But needless to say, migrations like this are not without challenge, especially in an organization of our size.

Now, if you’re not familiar with the wonderful world of Type JavaScript, before TypeScript, we would be using Flow, which is the type system that Facebook built, which seemed like a good choice at the time because we were using React. But over time, TypeScript became a much more popular typed JavaScript language. And we were increasingly finding that there weren’t any Flow types for the libraries that we were using. So it became really hard to upgrade some of our core libraries. The Flow server crashed all the time, which was infuriating.

And as well, we were using Next.js to build our main app. And we found that we were stuck using their old fashioned Babel-based compiler because their new fancy Rust compiler wouldn’t allow us to compile Flow.

And it was something that we talked about on and off for a while. We should probably do this at some point. We knew it was going to take a really long time. But it was going to be becoming too difficult to upgrade some of our tooling. And we knew that it wouldn’t be as simple as just running some kind of script to migrate everything all at once because, for one thing, there was just so much code.

And it can seem really intimidating when you’re right at the beginning and you feel like you’ve got this massive job ahead of you. Where do you even start?

Well, you start small. So in our case, a couple of our engineers decided today was the day. And so they had a bit of a hack. They looked on GitHub to see what kind of other things that people had put on there to see what they could use to try and migrate one of our libraries. They had a hack. They migrated one package. Then they got it building in CI.

Now, Flow to TypeScript is, unfortunately, a very well trodden path at this point.

And in fact, a while after we started, Stripe had done the same thing. And they open sourced the migration tooling as well. So whenever you’re embarking on a big technical migration, it’s always worth seeing what other people have been doing and what they’ve put on websites like GitHub to see if you can save yourself a bit of time.

When doing something like a migration, you want to prove that this can work before you commit yourself to doing anything else. If you try and get buy-in from, say, your boss before you’ve even started looking to a solution, you run the risk of it being shut down before you’ve even had a chance to do anything.

Without a really clearly defined plan and timeline of how you’re going to do this, you’re basically asking people with very little context to let you focus on what they might see as a less important piece of maintenance work over prioritized teamwork.

And it’s really important within your organization to have that space to experiment with something before you need to go and make a case for why you should do it.

So time box that exploration effort and communicate your progress really clearly as well. Keep a log of any decisions that led to you choosing a particular path or technology because someone in the future will thank you for it, whether that’s somebody else doing something similar in the future or you in six months wondering what the hell you were thinking.

So document the hell out of everything from the start. And for every new engineer who joins your team, you’re going to want to get them up to speed with everything that you’re doing and why you’re doing it.

I actually left Monzo in 2021, and I came back in 2022, which is a story for the pub afterwards.

But when I left, they were just getting started with experimenting with this migration.

And by the time I came back, it was going ahead. They’d already got halfway through. Loads of stuff was happening. So I needed to know, how can I get involved? What do I need to do? Luckily, my team had put together this kind of dedicated notion space with all the information about what was happening and how far we’d got.

Your documentation should cover every aspect of your project, past, present, and future. And it is a project, right? And of course, your projects are all meticulously documented, I hope.

But you need to make sure, as I said, it’s easy for somebody with no context to get up to speed with what, how, who should they talk to if they have any questions.

So once you’ve decided to do the work, who should actually do it? Should you have one team working on nothing but the migration? Or should you have lots of different teams

doing a little bit at a time?

In an ideal world, you’d have one team who just focus on that and nothing else. Because for one thing, it massively reduces the risk of things not getting done. That’s the only thing they need to do.

If you’re sharing the work among a lot of different teams,

you’re sure you don’t have to put people aside for the entire duration of the project. But it does take a lot longer.

And ultimately, if you’re asking people to do this work on top of their existing work, you’re going to be at the mercy of teams’ planning cycles. And this work is never going to be a priority compared to what they’ve already agreed to do in their team. And the bigger your organization gets, the more complicated this becomes. So if you’ve got one team just doing the migration, you don’t have to worry about that.

In our case, we couldn’t really have one team just doing everything. So we split the work across all of our teams that had Web Engine is in.

And we started with a small group of people who wanted to have a go. And we knew that it would probably take a while.

So how should you tackle the work itself? Should you go all at once? Or should you do it piece by piece?

Well, if you’re doing the work shared across multiple teams like we were, you don’t really have a choice. You have to go incrementally. But if you do have the luxury of a dedicated team doing this work, you can choose how you approach it.

Things like major version upgrades of big libraries should probably be done all in one go, especially if you can’t have more than one version running alongside each other. If you’re re-platforming your website on, say, a new static site generator, you might decide that you’d rather do it all at once. So you don’t have to mess around with things like multiple build steps and all of that stuff. Also, if the code base is a lot smaller, you probably haven’t got much at risk there.

And the big bang migration is going to be quicker, but it will be inherently riskier for larger code bases like ours.

If there’s an incident, which there probably will be, it makes it a lot easier to identify what’s gone wrong and roll it back if you’ve only migrated a little bit at a time. And it’s a much safer approach.

We have a mono repo for our Stins. All of our apps use React. Some of them use Next.js. And previously, they were all using Flow. And we have a lot of shared libraries across this mono repo that all have lots of dependencies across apps. And so changes to one little library can affect a lot of different apps and even parts of the same app. So we need to be very careful when we’re migrating to make sure that we were testing everything and being very diligent. Because ultimately, we couldn’t just migrate the entire customer service app and just throw it into production, because we need it to be able to serve our customers.

So the flip side of this is that you need to be very disciplined and make sure that you actually keep going, because it can be really challenging to maintain enthusiasm and pace, which we very much discovered. And there is a real risk that you go bit by bit, and then something else comes up. And you say, OK, we’ll just put this on hold for a little while, but you never come back to it.

Of course, like with any migration, we hit a bend in the road pretty soon.

When contributing to our repo, we found that people kept copying and pasting old flow packages and making new ones out of them, which was increasing the amount of flow code when we were trying to get that number down.

So we needed to make it so easy to build things in TypeScript that it was the only way. And we did that with tooling.

So we wrote a script, a package generator, that would bootstrap a new TypeScript library or component just the way you want it, with just a line of bash, basically, with all the things you needed.

And this removed a lot of the manual steps that engineers were struggling with and made sure that all the new things coming in were TypeScript.

We could have also added some static checks here. So tools like Semgrep will allow you to throw errors and fail your CI, for example, if people add in code that shouldn’t be there or use programming constructs that shouldn’t be there. And things like tools like ESLint are great for making sure that people don’t use imports from libraries that you’re trying to get rid of, for example.

I can’t say this enough. Tooling is so important with any technical migration. Because if we’d done this all by hand, it would have taken us so much longer.

So that script that our engineers wrote to see if they could migrate something to TypeScript became our actual migration script.

And after running that, you do it on a directory, and then you give it a look over to check for any type errors and any any’s, because we didn’t want any of those.

And because they’re good people, they wrote documentation. So we also had a space underneath for people to write down any issues that they come across during the process and how they fixed them.

The scripts also generated flow types for the libraries that we just migrated so that any other apps that hadn’t yet been migrated would still have those flow types for those dependencies.

Now, as I mentioned, we have this money repo with lots of shared libraries. And these libraries have transitive dependencies on other libraries. And this is obviously a vast simplification. But we didn’t want to be in a position where we’d migrate something to TypeScript and find that it still depended on libraries that were still in flow, because there wouldn’t be any types. So we wrote another script. This is a theme here.

We wrote another script to find packages that were ready to migrate, because all of their dependencies had already been migrated.

And as we went, we unlocked packages further down that dependency tree.

Now, especially with an incremental migration like this, it became really important to measure our progress, not only to keep morale up, but to see how close we were, or not in some cases, to actually finishing the migration.

And I put together a dashboard that showed the number of flow packages in the repo versus the number of TypeScript packages. And it was a really exciting day when those lines finally crossed over.

And wrote another script to tell me the percentage of files that had been migrated in the repository. And we used this to keep track of our progress. I posted it in Slack every month. And towards the end, I posted it every time the percentage changed as well.

And along with that measurement, you need milestones as well, which are checkpoints along the way. That indicate significant achievements in your migration.

And setting these milestones not only made us feel like we were getting somewhere, but it also helped us communicate our progress to stakeholders in terms that they could easily understand.

So the first app we migrated was a milestone. Migrating our business banking web app was another. And migrating our customer service app, by far the biggest app, was the final one. And if you’re not setting milestones like these for your projects, I really, really, really recommend it. Because it really helps to break down a massive project in easily digestible chunks. And it doesn’t feel like you have to wait till the end until you actually get any value out of it.

Unfortunately, another bend in the road showed up around mid-2023.

By this point, we had the whole web team working on the migration. But we were still quite a long way from the end. And we’d really hoped to get it done by the end of 2023. But it really wasn’t looking very likely.

And at my company, we tried to foster an environment where you have the ability to say, oh, as well as my team work this week, I’m going to spend Friday afternoon doing a bit of maintenance. Or I’ve got a bit of web work to do as well, doing this TypeScript migration. Which is great. Engineers can absolutely do that. But ultimately, we’re a bank. We have lots of external deadlines that we need to adhere to. There’s always a lot going on. And there’s various reasons why people find this kind of thing hard to prioritize. So either way, things were moving really slowly. And there was a risk that we just wouldn’t finish at all.

So we’d been roughly aiming for the end of 2023. But with the support of my engineering director, I turned this into a hard deadline. We had to get it finished by the end of the year so that we could be done with it. And we could all move on with our lives.

So we ticketed up the remaining work, break down the biggest remaining app into tickets, which we then gave to teams based on things like code ownership and team size. And I got buy-in from the engineering managers and the team leads of the ones with web engineers in to make sure that they brought those TypeScript tickets into their planning.

And every month, I counted up the remaining tickets for each team, posted that update with our progress and that percentage, and also made sure to celebrate the teams who had done the most that month as well.

We also reduced the scope of the migration a bit. So we wouldn’t have to migrate every single thing in the repo to consider it done. Only the ones that we worked on most. And this was a big compromise because it meant that we wouldn’t have migrated 100% of our code to TypeScript by the end.

But it was the only way we were gonna see the end of it. So yeah, these apps rarely got touched and people could always just migrate them when they needed to if they wanted.

We also wondered whether we could just strip out Flow because ultimately if you remove the TypeSystem, it’s just JavaScript. You don’t need to do any transpiling. But we realized that we’d have to still run some kind of script to migrate it to not Flow. And then we’d have to check it afterwards to see if it still worked. So it’s exactly the same process to get it to TypeScript. So we might as well just do that. So we thought we’d carry on.

Now we didn’t have to get particular buy-in for quite a long time because as I mentioned at Monzo, there is this certain expectation that there is this maintenance and engineering discipline work that happens alongside your teamwork. And for a long while, it was just a small group of people doing bits on the side here and there. But getting buy-in became really important later in the project once we’d proven the potential value and it was obvious that things were progressing very slowly and we knew that we had to get things done.

And without the back end of senior stakeholders, there was a real risk that the work wouldn’t be deemed important enough to actually finish. And my engineering director was a really great supporter here because with his backing, other less technical stakeholders in the business were much more likely to just let us get on with it.

And we brought managers and leadership on board by clearly articulating the problems we were having now and the benefits we were expecting at the end. And I had to make it really clear that we wouldn’t see some of these benefits until we had actually finished. Like things like compile time improvements.

And it really helps if you know what stakeholders care most about. And some of them are gonna be very focused on risk. Like what’s the danger if you don’t do the migration?

Others might be more focused on cost or developer velocity. So as being on an old version of some library, making you unable to ship.

Is this holding you back from scaling your organization?

Know who you’re pitching your argument to and tailor it so that they’ll be much more persuaded.

And stakeholders are also going to want to know when you see the benefits from all of this hard work. And with some migrations, it really is zero to one, right? You won’t see the value until it’s completely done. And for a lot of the TypeScript stuff, that was the case, right? So we could migrate 99% of our packages, but if there was any flow code left in the app, we’d still need to use the old compiler.

But there was a small amount of incremental value, it turned out, in being able to work in TypeScript because all the new stuff we were building was TypeScript. So we got to take advantage of better documentation and faster compile time in those libraries. And we were able to upgrade some of our libraries a bit sooner than we’d anticipated, which is great.

In my opinion, the greatest threat to any migration is not complexity, it’s actually changing organizational priorities that leave you unable to finish it. And make sure the powers that be understand the risks of not completing the migration.

It’s really easy to think you can just pause it and come back to it another time, but in some cases you’re gonna end up in a worse position than you were when you started.

I’m contractually obliged to include this XKCD comic here about standards. The message is you might introduce one new technology to replace everything, but if you don’t finish it, it’s just gonna be one more technology to add to the pile.

Maybe you’ll do a little bit of your migration, then you’re gonna need to focus on something else, so you go away for a while, and then someone else is gonna come along and add a new technology to the pile on top of it. Or maybe you’ve got a lot of different teams working on different parts of a website, and you’re using very slightly different approaches and different libraries. And I’ve been in a team like that a long time ago, and I can say it wasn’t a good time. But it’s also very common after mergers and takeovers when all the other company’s systems get absorbed into the parent company’s code base, and you end up with a lot of different tech stacks.

When there are five different ways of doing the same thing in your code base, like how is an engineer supposed to know which one the right one is? And what is their motivation to update the old stuff and replace it with new stuff if there’s still a lot of the old stuff?

And if someone is paged for an incident, and this particular part of your website uses some obscure data fetching library, when the rest of your website uses something normal, what are they gonna do? And think about the end user as well, right? Those of us who build for the web, like by adding a new library, are you increasing the size of the bundle that your user then has to download?

You’re also much more likely to get buy-in if you’ve proven that you’ve given a lot of thought to the safety of the migration. So minimizing disruption to operations, not inconveniencing people too much, and also having an escape plan.

Because any migration comes with risk, the important thing is how you deal with that risk and prepare yourself for what can go wrong.

Type system migrations, probably fairly low risk as they go, especially as we were moving incrementally, but that’s not to say it went perfectly smoothly, of course, but for the next section, I’ve drawn a little bit of inspiration from some other recent migrations that we’ve done that have carried with them a bit more risk.

And Montes, we have a value, which is be hard on problems, not people, which I really like. Ultimately, when things go wrong, there’s always a root cause, and it’s very rarely, if ever, a human’s fault, right? If someone did something they shouldn’t have done, what happened to make them able to do that thing?

Incidents happen, and they are an inevitable consequence of doing stuff and, you know, moving forward, shipping code,

except that you will probably have some incidents, and that is okay.

The important thing is that you can recover from them quickly and safely, and learn from them so they don’t happen again.

We almost certainly had some bugs that arose from shipping code that we’d migrated to TypeScript, but we could roll them back really quickly, fix the problem, and make sure that we didn’t do that again.

It might be appropriate to establish a set of guardrails, which are points at which you will no longer be happy with what you’ve done and roll it back.

So, for example, if you’re migrating your website to a new platform, you might wanna monitor the performance and load times and say, okay, if load times consistently exceed X, then we’re gonna roll back.

And you should make sure you have the same metrics across the old and the new systems so that you can compare. So you might wanna have some dashboards or something, which can give you an idea of how things are looking across both implementations. So we recently migrated our customer phone call tooling to a new platform. And we had side-by-side dashboards showing things like call answer rate, queue lengths, and the number of people who were on a call.

And if we saw massively different results across the two systems, we knew that something was wrong. And we also set alarms on these metrics so that we would be alerted and we didn’t have to sit there watching dashboards all day. And we also worked with the folks in operations to understand what are acceptable levels for these metrics. Like, at what point should we say, “Oh, that’s not good,” and turn it off?

And if you do hit one of those guardrails and you make the decision to roll back, you need to make sure that you’ve got a really well-documented way of doing that.

And anyone should be able to follow that plan, not just you, especially if they’re paged in the middle of the night.

And, okay, with the TypeScript migration, we didn’t have a rollback plan because we figured nothing that bad could go wrong.

We’d validated very early on that there was negligible impact in build times when TypeScript went into the mix. And it all just compiles down to JavaScript anyway. But other migrations have a lot more at stake. So my colleague, Sahil, spoke at a Staff Plus conference last year about some of the migrations that our platform team have done. And these migrations touch the services that literally power the bank.

So when critical functionality is in the hot path for your migration, you need to make really sure that there’s a really well-defined escape plan if things do go wrong. And this might be a complete rollback of the system or a partial rollback to a point that you know is safe.

And there’s going to come a point where it’s not safe anymore to rollback.

And ideally, this should be closer to the end of your migration. But make sure that’s also really well-documented because it can actually be quite destructive if somebody tries to roll something back when you’ve already gone past the point it’s safe to do that.

And, like, growing out a bad haircut, there’s probably going to be a really awkward in-between phase where you’ll have the old and the new technologies running alongside each other. You’ll have to maintain and make changes to both of them.

You might have to have some temporary slowdowns in your build processes, like additional build steps. Like, we had to run both the flow and TypeScript compilers alongside each other, which, you know, it was a really small effect. But ultimately, that was a couple of seconds on every build. But keep going, and eventually, you’ll get to the point where you can remove the old system.

And we did it. So, in December last year, I was running the migration stats script more frequently to see that number ticking up, 97, 98, 99. And towards Christmas, I PR’d a change that was just like the remaining flow files in the main app. It turned out my script never got to 100% because it was just looking for JavaScript files, and there were always going to be JavaScript files in the root of the project. But I know I got to 100%.

And when I came back from my break in January, I removed Babel from the biggest customer service app to see what would happen,

expecting to find that we’d forgotten something or that some setting was misconfigured. But it just worked.

And it was great. The compiler was faster in both development and CI. We could upgrade some of those packages sooner than we thought.

We did find a concerning number of type errors in our code that were actual missing parameters and props that Flow had just kind of blissfully ignored. And we found that our IDEs were a lot faster as well. So a lot of us use VS code, which works really, really nicely with TypeScript as well.

And when you do finish, because you totally will, make sure that you celebrate it. It’s not an easy task doing a technical migration, and it can take a really long time, as it certainly did in our case. So make sure that you recognize everyone who contributed and saw it through with you.

In my case, I posted a message in a public forum. I love to publicly embarrass people by telling them how great they are in very public forums. And this one was in our company-wide engineering announcements channel. So make sure engineering leadership know what you’ve all achieved as well. We got stickers made, as I said. Like everyone loves a sticker. If there wasn’t a sticker, did it even happen?

Also got some cakes made with little TypeScript cake toppers as well.

And that is a story of how we migrated to TypeScript. So now, how about your story? Next time a migration opportunity presents itself, I’m gonna give you some things to think about before you take the leap.

The first thing you should ask yourself, and you must always ask yourself this, is do you even need to do this migration at all? Like what happens if you don’t do anything? Will you be in the same place or a worse place? Because if you’re gonna be in a worse place, then yeah, you should probably do something about that. But if you’re gonna be in the same place, I encourage you to think about what you really get from this migration.

The decision to introduce a new technology needs to be really, really well considered.

Have a really, really clear idea of the benefits that you’re expecting to get, because ultimately, benefits are relative compared to the effort that you need to actually do the migration. Is there a point at which the number of developer hours actually outweighs the benefit that you’re expecting to get?

And this gets more and more of an issue, the bigger your code base gets and the bigger your organization gets as well.

Now for TypeScript, compilation time was a nice bonus, sure, but in reality, we knew we couldn’t afford to be stuck on an obsolete type system that fewer and fewer people knew how to use

and that nobody was writing TypeScript anymore. And it did take us a long time to get there, but it’s gonna continue to be worth it every time we’re able to upgrade one of our packages or someone comes along and joins us who already knows how to use TypeScript.

And remember that technology is not free once you’ve implemented it, right? There’s maintenance to think about.

Who is gonna look after the new technology? And this includes staying on top of vulnerabilities, like being on call if that’s relevant for your organization, doing major version upgrades, debugging when things inevitably go wrong.

And make sure you don’t think you can just hand it over to an infrastructure team and expect them to magically know how to look after it.

And does more than one person in your team know how this technology works? Okay, and this totally applies to things like new software as well, right? You might think it is amazing, but does anyone else know how to use it? And if you left the company, would anybody else be able to pick up where you left off? Are the other engineers reasonably ready to change their ways of working? Like, do they have the time to learn how to use this new thing? I keep coming back to GraphQL, but I think it’s just such a great example, right, of a tool that can be introduced and kind of cause a lot more problems than you might think, right, because something like GraphQL requires a massive paradigm shift in the way that you write APIs. And if you haven’t kind of brought your engineers, the other engineers along the journey with you, then you can end up just building something that isn’t a graph at all.

If you started a brand new project today and you chose whatever new technology to build your project in, you know full well you’re gonna be going through exactly the same process a few years down the line because there’s always going to be new technology in the same way that all code is legacy code as soon as it’s merged into the main branch.

And you don’t have to do a migration every time something new comes out. So think very carefully about your motivations.

There’s a massive difference between picking something because it seems cool and picking a new tool because it’s genuinely going to be better than what you had.

Many of us have built some horrible workarounds and really nasty functionality in our careers

because there just wasn’t something that existed at the time but then in more recent times, things will have come out that have actually replaced that.

Things become end of life as well, right? So we might put off major version upgrades of packages because we’re intimidated by the amount of work required. But it does become a necessity at the point where they’re no longer updating the old version and you’re at risk of security vulnerabilities not being patched.

And things that seem like a good idea at the time might end up being a really poor decision.

Have you ended up with the technology equivalent of HDDVD in your code base? If you’re not familiar, HDDVD was the competitor to Blu-ray,

the kind of early 21st century beta max.

And Blu-ray won the war of the standards. HDDVD disappeared, never to be seen again. If anyone had an Xbox 360, that had an HDDVD player in.

Many of us will have bet on the wrong horse when it came to technology decisions. Then for us, flow turned out to be our HDDVD.

So we made a choice in the past and it turned out not to have been the right one. We certainly weren’t the only ones to have made that decision and it made a lot of sense at the time. These things happen, that’s fine.

Sometimes a library or a technology will be deprecated in favor of something else. And that can leave you at a real disadvantage as we discovered when it comes to upgrading things or taking advantage of new advances in technology.

As well as a lot of good reasons, there are also some quite bad reasons to do a migration.

Sometimes companies migrate to new technologies because it just seems like that’s what the industry is doing now. Don’t assume that just because a well-respected tech company is using a particular technology, that you should as well.

When everyone was adopting React, I do wonder how many of them actually stopped to think about whether they needed a framework that was built for a Facebook scale application.

Now we use it internally at Monzo for our customer service system, but that is massive and very complex and has a lot of contributors. And I actually think that’s quite a good use case. But for a static page that you’re serving to customers, like how much of it is just excess JavaScript that you’re sending down the wire? And can you achieve the same effects with a less exciting static site generator?

Or maybe you joined a new company, or you came onto a new project where they’re using a new technology or library that maybe you’re not familiar with or you don’t like very much.

I was given some good advice by my boss at a new company once when I said I didn’t like a library that they’d chosen. He said, “Live with it for a few weeks. Think about whether it is actually worse or if it’s just different from what you’re used to.” And I think that is really, really good advice, right? Is it actually worse than the other thing you would have used, or is it just different?

Now, in my case, I do think it was actually worse and I was right, but the principle is a good one.

By not opening your mind to different technologies from the ones you’re used to, are you holding your work and yourself back?

And even if the other technology that you would have used actually is better, like does migrating to it make sense? Like if you’re working at a small startup, does it make sense for them to spend their time migrating to some new technology?

And considering how long migrations can take, is it really, really worth it?

Or maybe there’s a new language that you’ve been playing with in your spare time and you just wish you could use it all the time. Or there’s massive hype around a new technology and it seems like it would be good for some reason or another.

There are so many new libraries and frameworks and languages out there and it is absolutely exhausting trying to keep up with them. And most of them will come and go before you’ve even had a chance to try them out. And it’s really, really important to consider whether a new technology is actually better than what you’ve got now.

There’s nothing wrong with boring, right? Boring works, boring is tried and tested and boring is easier to maintain.

This is an excerpt from an essay called “Choose Boring Technology” by Dana Kinley and I make everyone read it. Boringtechnology.club is the website. But it goes, “Boring should not be conflated with bad. There is technology out there that is both boring and bad. You should not use any of that. But there are many choices of technology that are both boring and good, or at least good enough. MySQL is boring. Postgres is boring. PHP is boring. Python is boring. Memcached is boring. Cron is boring. These technologies, boring though they are, are familiar and reliable. People know how to use them. And there’s lots of documentation. They’re very well tested and well maintained. And sure, they’re not new and exciting, but they’ll do what you need them to do.

I hope that these lessons will give you something out of a framework to tackle your next migration, whether you’re a big company or a small agency.

And even if you don’t work on the technical side of things, maybe there’s some stuff that you can take away as well because ultimately we all find ourselves making these kind of shifts to new technology, whatever we’re doing, right?

And when you do do a migration, do it wisely. Don’t be afraid to be boring and remember that maybe you don’t even need to do it at all.

Thank you very much.

(Applause)