Ask the vendor when the platform will be doing real work, then plan for everything before that date. Nobody puts this story in the vendor’s case study, and it is the most useful part of a migration. A programmer on my team kept the migration moving with a tool he built and named himself, while the platform we’d paid for was still being brought up. A business case that never admits that gap exists is sloppy.
What is the buy versus build decision really about?
Not which one is better. Which one you’ll be running in six months.
Ask the vendor when the platform will be doing real work, then plan for everything before that date.
The argument gets framed as a permanent choice. Buy for speed and support, build for control and fit. Both cases are reasonable and both get made in every company.
What the framing misses is time. A purchased platform doesn’t start working the day you sign the contract. It gets configured, integrated, tested, and adopted, and that takes months.
During those months the business still needs the thing done. Nobody puts that period in the business case, and it’s where a lot of real engineering happens. I think leaving it out is wishful accounting, and the people who pay for it are the engineers told to keep everything running with a tool that doesn’t work yet.
Why do enterprise platforms take so long to implement?
Because the product is general and your business isn’t. Vendors build enterprise software to serve many companies. That means it arrives capable of a great deal and configured for nothing. Everything specific to how you work has to be added.
Add integration with the systems you already run, data mapping between formats that were never designed to meet, testing against real volumes, and training for people who didn’t ask for a new tool. Months disappear into those four things.
The purchase can be exactly right and still be the beginning of a project instead of the end of one. Business cases are frequently written the other way, and I blame the sales cycle for that, because nobody closes a deal by describing the months of integration work ahead.
What do you do while the platform is being implemented?
In our case, one programmer and his team wrote something and called it DataSlide. We were in the middle of the second transformation, moving off a declining database onto a new platform. Part of the plan was enterprise middleware that would move data between the old systems and the new ones and between the databases themselves. The middleware wasn’t ready. The migration was. So a programmer on my team built a set of programs that slid data from one system to another. Extract it, convert it, load it somewhere else. He named it himself. It worked. It moved the data while the purchased platform was still being brought up, and the migration kept moving because of it. I’m still proud of what that team pulled off with so little fanfare.
Is an interim solution worth building?
When the gap is real and the business can’t wait, yes.
The objection is obvious. You’re building the thing you just paid somebody else to provide, and now you have two of them.
Three things make it worth doing anyway. The interim version only has to handle your cases instead of every company’s, so it’s far smaller than the product. People who already understand your data can build it. And you can throw it away without regret, because it was never meant to last.
That last condition separates a good interim solution from a problem. Build it knowing it dies, keep it small, and don’t let it grow features.
The failure mode is the interim tool becoming permanent because it works and nobody wants to finish the migration. Set a date for retiring it when you build it.
What does an enterprise sales process tell you?
Something about the vendor, and less about the product than you’d hope. The middleware company we bought from had a headquarters within walking distance. Beautiful building, obviously overbuilt, marble floors. Built to impress buyers.
They wanted to sell the company, and they did. A major technology firm acquired them for around three hundred and eighty-seven million dollars in 2005. My boss loved that company. The building did its job. None of that made it a bad purchase. The product was real and the acquisition proved somebody else agreed. What the building told us was about the vendor’s ambitions, and a buyer should know which signals are about the product and which are about the sale.
How should a small company handle the implementation gap?
Ask one question during the sales process and get the answer in writing.
When will this platform be doing real work for us, and what are we doing between now and then?
A vendor who has implemented for companies your size will answer in detail. They’ll describe the phases, name what typically slips, and tell you what other customers did in the meantime. A vendor who answers with a fast onboarding timeline and no discussion of the gap has told you something too.
Then plan the gap deliberately. There are three possible answers. Keep the old system running longer than planned. That costs money and buys certainty. Build something small and temporary. That costs engineering time and requires the discipline to kill it. Or accept the business does without. That’s sometimes fine and should be a decision instead of a surprise.
| Option | What it costs | What it requires |
|---|---|---|
| Keep the old system running longer | Money | Buys certainty while the platform comes up |
| Build something small and temporary | Engineering time | Discipline to kill it, a retirement date, no new features |
| Let the business do without | Going without the function | Sometimes fine, but made as a decision, not a surprise |
| The default: nobody plans for it | A scramble in month four | Nothing, which is the problem |
Any of those beats the default: discovering in month four that nobody thought about it. When that happens, I put the blame on whoever signed off on the plan without asking, and the people who pay are the ones scrambling to cover the gap.
My take
Plan for the gap before you sign the platform contract. Implementation takes longer than the business can wait, every time. We bought middleware, and a small team wrote a workaround that shipped first. I’d do that again. Keep the interim tool small, give it a retirement date the day you build it, and refuse to add features. The danger is a workaround that works so well nobody finishes the migration.
What did DataSlide prove about the purchase?
Both decisions were correct at the same time.
The middleware was the right long-term choice for a company running many systems that needed to talk to each other. Buying it was sound. And the thing that moved the data when we needed data moved was written in-house by a programmer with a name he made up for it.
The purchased platform had a marble headquarters and a nine-figure exit, and the interim tool had a programmer and a deadline. Both were part of the same successful migration. It galls me that only the first one ever shows up in accounts of how these projects work, because people who write small tools like DataSlide are a big reason expensive purchases end up looking good on paper.
