James and Steve share stories from their early careers, explore the lessons learned, and reveal how the right methodology, mindset, and people can turn a disaster into a smooth delivery.

If you’ve ever been on a project that was going off the rails, this one’s for YOU!

🎧 Subscribe, listen in, and let’s make data migration a little less painful.

In this, we discussed:

• Real-life data migration disasters (and why they happen)

• How poor planning and patchy leadership cause project chaos

• Why automation saves time, stress, and sanity

• The sneaky dangers of spreadsheets

• Building a calm, confident cutover process

• Why people, trust, and validation matter more than ever

EPISODE TRANSCRIPTION:

Disclaimer: This transcript was generated by an AI tool that did its best, but it's never met different British accents it could fully decode. Expect a few funny mistakes. Enjoy!

[00:00] - James B

Hi, I'm James Blake, Chief Executive of binary10, and welcome to the Data Migration Podcast.

[00:08] - Andi J

Hello, and welcome back to the binary10 Podcast on data migration. I am joined today by Jamie Blake, CEO, and Steve Smales, COO, to talk about data migration disasters, and importantly, how you avoid them.

I think it's fair to say, gents, isn't it, that anyone who's involved in data migration has seen a disaster or two?

[00:29] - James B

Absolutely. A hundred percent, yeah. But luckily, only one or two, but heard of lots of others.

[00:34] - Andi J

I also get the feeling that you may be talking from personal experience there as well, Jamie.

[00:38] - James B

Yeah, I think so. I'd like to say that not recently, because we've done a lot of hard work to prevent these things.

But yes, in the early days of my career, and when I first started data migration, sometimes I didn't realise how much of a disaster they were. At the time, I just thought it was a usual thing. But no, I've experienced quite a few, and lots of different reasons why they happen.

And that's why I've become quite passionate about putting a methodology together, doing it the right way, because it was so disappointing, and just not nice to see.

[01:11] - Andi J

It's worth noting, Steve, isn't it, that it's not just small companies who can sometimes have DM disasters. It can happen in quite high-profile cases, can't it?

[01:23]- Steve S

Oh, absolutely. I mean, I did a data migration project for a very large media company once, a very well-known media company. And they were sort of merging two companies. And it was a bit of a strange setup, because I was working for the consultancy that did all the financial side of things.

And a different consultancy was doing all the HR and payroll. And our side went very smoothly. We went live on time, but there were delays on the HR payroll side.

And then we'd left the building. Elvis had left the building. And I heard a few months later from one of the project managers there that the HR and payroll had gone live about two months late and was a disaster.

And back to that word again, disaster. And they couldn't fix it. And they had to get in one of the big consultancies to try and sort it out, who then said, no, complete re-implementation of the system from scratch.

So it cost them an absolute fortune and delayed their go live by a year.

[02:17] - Andi J

And what lessons do you learn from that? Not personally, but from that sort of project, what are the factors that cause those projects to end in disaster, really?

[02:26] - Steve S

Well, I think on that particular one, you've also got two different consultancies. And that's probably not a good idea. Because you're going to get, to be honest, there wasn't really any conflicts as such. But they were two separate projects, really, with not an awful lot of interaction between them. So it was, I suppose, a feasible idea.But it's getting the right consultancy, isn't it? And getting people in who know what they're doing. And clearly, I can't speak for that consultancy on their experience or their knowledge. But there was something obviously not quite right there. And I don't know if it was on the testing side or the reconciliation that they hadn't thought through properly or just the planning. But something went very badly wrong. And we only saw it from the other side of the room.So we don't know the full details. But it's strange when you've got one consultancy does it spot on, the other one gets it horrendously wrong. So it's difficult to know without the specifics what was the actual cause of that problem. But we've seen it on numerous projects. And it's normally down to bad planning, lack of adequate testing, lack of adequate reconciliation.

[03:29] - James B

And probably a little bit of that leadership as well.

As you say, the reality is that the more third parties that are part of that project, they have their own agenda. They've got to deliver based on their contracts. So having that kind of central program leadership and supporting leadership team is just critical to make sure they are working together.

That naturally, they will have their own self-bias. And that's where I think methodology, framework, how you all work together, how you log things, check things, validate things. People always don't like the documentation side of what we do.

Oh, I've got to write a document. I've got to capture that. But if you don't, if you allow yourself to get too slack, these are the things that happen.

Because it's very difficult for consultancies or individuals to put their hand up and say, I made a mistake here. Or something's not quite working here. It's a lot more easier for people to stay quiet.

[04:21] - Andi J

And we talked on a previous episode about how maybe data migration projects don't happen all the time in organizations. They come along infrequently sometimes. So does that cause a procurement problem as well? That perhaps procurement functions don't necessarily know what they're purchasing at the time?

[04:39] - James B

I think it does.

I think it causes a big problem because it comes a bit like we had a previous episode where we talked about planning. And that's extremely important. But you almost need to do a level of planning so you know who to bring in and who needs to be involved.

And I think it's very difficult to get that right. And what you tend to find happen is that people join piecemeal bit by bit at certain stages of the actual project delivery. And that can then make it more challenging to bring everyone together.

And the reality is we're all human. You can have individuals that come in that can actually be quite disruptive or have a different personality or want to do things differently. So, bedding in that foundation, getting that right leadership team in early so they have that structure, they have that control, you're on a great start.

[05:25] - Andi J

Human error can be a challenge, can't it, sometimes in data migration projects?

[05:28] - Steve S

Oh yes. I mean horrendous because particularly when we've seen certain projects before where it's all been done by people manipulating spreadsheets manually. And of course, it's just open for not just human error, but Excel can strip out the leading zeros of things and suddenly your phone numbers aren't right or something like that. So there's all sorts of things you need to consider. But anything you can do to minimise human error, the better. So we like to, as part of our binary10 methodology, we like to have automated processes where there's next to no human interaction as well, apart from somebody after it's all been written and tested, kick it off a procedure, an automated procedure.

But the other good thing about that, it's repeatable. You run it again and again and again, you get the same results. Now if you're doing it manually, that's quite often not going to be the case.

[06:14] - Andi J

Is there anything that a data migration specialist dislikes more than somebody saying we've got this data on a spreadsheet?

[06:18] - Steve S

To be honest, it's not too bad, things being on a spreadsheet, and we do get a lot of spreadsheets. Now from our point of view, it's much, much better if you're extracting data from a system because you know what you're getting. It's a standard format.

The problem with spreadsheets, yeah, they can change from one week to the next and people are adding different columns or again, we're back to the human error on spreadsheets. So spreadsheets, they can be a bit of a pain, but it's a necessary evil as such. We have to deal with them, and particularly things like fixed assets.

So when we're talking about the finance system, quite often fixed assets are on spreadsheets. So it's not something we can avoid. I suppose it's just having experienced it for so many years, we're aware of the pitfalls that you can have with spreadsheets.

[07:08] - Andi J

I think in your world of data migration, there's a lot of maybe messiness for an untechnical world of different systems, spreadsheets, data held in different ways that you're trying to standardise and move across, and the quality analysis must be really important to avoid those disasters.

[07:25] - James B

Absolutely, it's huge. You know, Steve says many times, get ahead on your data.

Understand what is wrong with your data. Don't wait until the new system's in, we're testing, we're trying to get data in, because by that time you'll get hit with 100 issues and it will take weeks and weeks and months to solve, and that can impact your plan. So if you can get in early, and good data people will know what they're checking for, address formats, whether it be invalid characters and names, things like that.

It's so important to do that analysis on the data and try and correct it, even before you kick off the programme, because it will save you that time in the long run. But also, it's also about not getting over the top with data quality, because actually that data is working in your system, might not be perfectly efficient, but it's good enough. So another important thing there is making sure you get the balance right, that you're not trying to clean it to the nth degree and continually polishing it when it's perfectly polished.

It's about getting that prioritisation right so that you're not impacting the delivery, because at the end of the day, that's the thing that's the most costly. Any delays on that is costly.

[08:32] - Steve S

Yeah, and the other thing you need to consider as well with data cleansing is that the clients, they have to cleanse their own data, we can't cleanse it for them.

We can advise them on where we've spot the issues and give them a list of things that we think are wrong, but they've got to fix it in their, ideally, in their legacy systems. And that's going to take time, so that needs to be factored into the plans as well. The actual data quality analysis that we would provide, and then the actual data cleanse that the client has to do with themselves.

So they need to have their resource lined up for that. And you don't want that happening just before you're going live, because you could create even more problems. So that, the sooner you start on the data analysis, the better.

[09:08] - Andi J

So having an experienced bunch of people working on this, or at least advising on this is critical to making sure you avoid a disaster.

[09:14] - Steve S

Absolutely, because you do need people who know what they're looking for in terms of the data issues. Now, as Jamie says, you don't need to look at every single piece of data.

You've got certain key data entities within those certain fields that you know that's key. And within those, you're looking at, have we got all the data? Is anything missing? Is it a correct format? We might need to make sure the data aligns with the config or the mappings that are being considered by the system implementers. So there's a lot involved in data analysis upfront.

[09:51] - James B

And actually, when you said that, it did make me shudder a little bit. So this is an experience. So this is one of the experiences I've had.

And actually, it wasn't a disaster. The disaster was avoided. But it was actually my first role as a lead.

So I've done many technical roles on data migration.

[10:08] - Andi J

This must have been a few years ago now, Jamie, maybe 30 or 40, 50, maybe?

[10:11] - James B

Be kind. Be kind.

I think it was probably about 20 years ago. I'd done a number of years doing it technically and then decided to lead it because I was getting frustrated by not being led in the right way. And it comes back to the people thing and the right people and trust.

And I remember we had a guy on the team. And I was kind of allowing them to just get on because I was still learning as well. And we had a setup where we had an individual that would be responsible for the whole end-to-end migration.

And that's where trust is so important because part of our methodology today, actually, we try and break that so that we allow people to mark their homework, if that makes sense, just so that we've got that oversight. It's actually probably come from me and this experience, which is we had a guy on the team that was responsible for purchase orders. And for the whole way through, all the reports were positive.

Yeah, they're all in. They're all loaded. Yeah, we're all looking positive.

And it was like, great. And he was a really confident guy until about two weeks before we were due to cut over. Someone else noticed some issues with purchase orders that were affecting some of their data.

And then very quickly, this person became uncontactable. They didn't turn up to work. They weren't there.

And it was essentially that the whole time, I think some of it was OK, but a lot of it was bad and not in the right place. And of course, I had been leading and reporting how wonderful it was going, and it was all great. And I tell you what, I was saved.

I'd like to call out his name, but I won't. But there was a chap that I worked with that was, the trust is there all the time now for me. And he took up the mantle, and he said, I'll get this sorted, and I'll get this corrected.

And I don't know how he did it, but he spent two weeks, long nights having to sort that out. And we managed to go live with minimal issue. And that was such a big moment in my career where I just thought, I can't let that happen again.

And that's a big people thing. How do you truly trust someone? We want to be personable. We want to get on.

But you do need to have some level of validation and doing it in such a way that people don't feel like you're looking over their shoulder or man marking them. So yeah, so that is definitely an example of where, luckily, a disaster was avoided. But yeah, that was a difficult day when they didn't turn up.

[12:13] - Andi J

So I think for that, Steve, there's a story in there, isn't it, about having the systems and processes so you can automate where possible, but also allow people the freedom within that space, which is what you've developed here, isn't it?

[12:27] - Steve S

That's right. So our methodology, we've got a certain structure to it. But our DM analysts, they've got a bit of freedom within that structure to do things the way they want to do it.

And we've naturally got sort of built into that structure. Yeah, we can bend it a bit. It can be adaptable to a certain extent, as long as the main overall structure is in place, the way we do things, basically doing things properly, doing things in a well-organized way that everyone is bought into and is aware of how it's going to work.

So that's our approach, really.

[12:58] - Andi J

And we've talked about DM being technical, and it is, but it's the sleepless nights for the people involved if it does look like it's becoming a disaster, isn't it? So there is a very human element to making sure that you avoid these.

[10:11] - James B

Oh, massively. And I'm a big promoter of this. I mean, I'm sure a few of us might put our hands up and say, whilst we care and we're passionate about this, we might want it to have been a footballer or a golfer or whatever. And it is hard work.

But I'm so passionate about it being enjoyable and just having a good time with your colleagues and all that sort of thing. And that's why, actually, half the time, we come in to some of our clients where they're already halfway through and it's going wrong. And that's the bit that really gets to me, because I see people and you see that they're working long hours and they're not getting it and they're trying hard.

But it's almost like we're in a technical world where no one gives you the praise when it's working, because people expect it to be working. But when it doesn't work and it's not going well, then the finger does get pointed and you're made to feel like you've let other people down. So it's so important that it comes back to a number of the points that we've raised today and on other podcasts about getting in early, getting those people right, making sure that everyone understands what they're doing.

And then you can open up that environment for that transparency, that honesty, and everyone can get on and you can have a good time. So I think for us, it's absolutely we have to deliver and that's our focus. But we want to deliver well and with fun and just people enjoying their lives and not having those sleepless nights.

[14:26] - Steve S

Yeah, we want it as far as possible to be a sort of, there's always going to be some stress in a big project. But I mean, as far as possible, you want it to be stress-free and particularly in the lead up to the cutover, which are very stressful times, let's be honest, and you're never going to avoid that. But we could try and make it as stress-free as possible by being organized and going through the right processes, so that when we're coming towards that cutover, everyone's confident.

And if everyone's confident, then there's a lot less stress. But I think a lot of it is just having experienced people sort of guiding that process. And we, as Jamie said, we've come in sort of halfway through projects before, where it's not going well, because the people brought into the data migration were data migration specialists, didn't have that knowledge of how to run a data migration project as part of the overall program.

And we've had to come in in a bad place and turn things around in a very short space of time. So it is key to get people in who know what they're doing on the data migration side. A lot of system implementers are asked about data migration from the clients.

And they might give an opinion, but then they're not specialists in data migration. And they might know about the actual importing of the data into the target system, because they're the experts in the target system. So they'll know about actually getting the data in.

But what they won't know about is all the stuff before that, that gets you to that point.

[15:52] - James B

Yeah, no, absolutely. It's a bit like mergers and acquisitions, isn't it? You know, sort of like that, I mean, it kind of covers all sectors, but it's a specific type of world, isn't it? Where, you know, it's a classic example of everyone's delighted, and they're all celebrating and popping the champagne, because we've won another client.

Yes, we've, you know, we've merged, you know, we've bought out, we're growing, and it's all great. But there's a back office crew that are pulling their hair out, because they're like, oh, my God, we've now got 20 systems to manage, and what are we going to do? Yeah. And it's like that back thought.

And so, you know, that's definitely an area where, you know, benefits so much from this approach and making sure that you're prepared for all these things, because eventually it will come back to bite, right? It will reduce the operational efficiency of the business. So yeah. Yeah!

[16:35] - Steve S

I did advise one client on mergers and acquisitions and said, you need to start thinking about your data in your discussions during, you know, the takeover process before you complete it.

Don't leave till afterwards, actually start talking about what systems are using, what are we going to do with this afterwards? When do we need to see the data as part of your, you know, acquisitions process?

[17:01] - Andi J

Well, two men who clearly enjoy the fact that experts and elbow deep in data migration. So, Steve and Jamie, thank you very much for your time today. Thank you.

[17:07] - James B

Thank you. And see you next time, Steve.

[17:09] - Steve S

See you next time!

[17:10] - James B

Thanks so much for joining us on our podcast. If you'd like to know more, please visit us at binary10.uk.com. And if you'd like to come and see more of our podcast, please subscribe.