Ask the vendor when the platform will be doing real work, then plan for everything before that date.
What is the buy versus build decision really about?
Not which one is better. Which one you will be running in six months.
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 does not start working the day the contract is signed. 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 is where a lot of real engineering happens.
Why do enterprise platforms take so long to implement?
Because the product is general and your business is not.
Enterprise software is built to serve many companies, which 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 did not ask for a new tool. Months disappear into those four things.
None of that means the purchase was wrong. It means the purchase was the beginning of a project rather than the end of one, and business cases are frequently written the other way.
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 was not 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.
Is an interim solution worth building?
When the gap is real and the business cannot wait, yes.
The objection is obvious. You are 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 rather than every company’s, so it is far smaller than the product. It can be built by people who already understand your data. And it can be thrown away without regret, because it was never meant to last.
That last condition is what separates a good interim solution from a problem. Build it knowing it dies, keep it small, and do not let it grow features.
The failure mode is the interim tool quietly 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 would 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 specifically. They will 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. It has three possible answers. Keep the old system running longer than planned, which costs money and buys certainty. Build something small and temporary, which costs engineering time and requires the discipline to kill it. Or accept the business does without, which is sometimes fine and should be a decision rather than a surprise.
Any of those is better than the default, which is discovering in month four that nobody thought about it.
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. The interim tool had a programmer and a deadline. Both were part of the same successful migration, and only one of them appears in any account of how these projects work.
The Guides That Get Your Book Written, Published, and Sold
Four short, practical guides on writing, publishing, and selling your book, plus the occasional note when there's something worth your time. No fluff, no daily inbox clutter. Drop your email and they're yours.
We use MailerLite to manage our list and send these emails. Your address is used only to send you what you signed up for. We will not sell it, share it, or use it for anything else, and you can unsubscribe anytime.