When your vendor gets bought, use the quiet week.

Monday, 8:40 a.m.

Picture the email. It lands before your first meeting, from someone at your software vendor with "Chief" in their title. The subject line has the word exciting in it. Two companies are joining forces. The products you rely on will have more resources behind them than ever. And, most important, nothing changes for you.

Someone on your team forwards it to the ops channel with a single question mark. Then everybody goes back to work.

A version of that email could land in a lot of inboxes this week. On Sunday, October 4, the Financial Times reported that Schneider Electric was nearing a deal to buy PTC, the Boston-based engineering software company, for about $20 billion. Reuters carried the report and said it couldn't immediately verify it. Bloomberg put the price at more than $20 billion and said an announcement could come as soon as Monday. Neither company had commented when the stories ran, and talks like these can still fall apart.

We don't know how this one ends, and for this note it doesn't matter much. If you're a PTC customer, this is your week. If you aren't, treat it as a rehearsal. Sooner or later a tool your business runs on will be the one in the headline, whether the buyer is a competitor, a bigger platform, or a private equity firm. The email always says the same thing.

Nothing changes on day one. That's the useful part.

The reassuring line is usually true, for now. Your contract doesn't rewrite itself on closing day. The login still works. Support still answers.

What can change comes later, and it tends to arrive quietly: a new price list at renewal, a product folded into a bundle, an API version retired with a long notice period, support moved onto the parent company's process, sign-in migrated to someone else's identity system, a roadmap item that slips because the new owner has different priorities. None of that is guaranteed. Plenty of products get better after an acquisition, with more money and more people behind them. But each of those changes lands on a date, and you'd rather see it coming.

So the first week is valuable precisely because nothing is happening yet. You have time, nobody is pushing a deadline at you, and you aren't negotiating under pressure.

There are two moves to avoid that week. One is migrating in a panic because the news felt bad. The other is signing an early multi-year renewal because a discount arrived alongside the press release. Both are decisions made on a feeling. Everything below is about swapping the feeling for evidence.

Find the dates before anyone calls you

Pull the actual contract, the order form, and any amendments. Not the summary someone typed into a spreadsheet two years ago. Then put these on one page:

• Term and renewal date. When does it end, and does it renew automatically?
• Notice window. How many days before renewal do you have to say you're leaving or want to renegotiate? This is the date that catches people.
• Price terms. Is there a cap on increases at renewal, or is the next price whatever the new list says?
• Assignment and change of control. Can the vendor hand your contract to the new owner without your consent, and does anything change for you if it does? Have your lawyer read this part. It's their call, not ours.
• Data terms. What does the contract say about exporting your data, in what format, and how long they keep it after you leave?
• Service levels and support. What's actually written down, as opposed to what you've gotten used to?

Next to each line, write a name: the person who will watch that date or chase that answer. A renewal date with nobody's name next to it is how teams end up auto-renewed into terms they never chose.

Write down what you rely on that nobody signed

This is the step most teams skip, and it covers the things most likely to change first.

Over the years you've collected promises that never made it into the contract. The sales engineer said the API you built against wasn't going anywhere. There's a support person who knows your setup and answers your emails directly. You were told a feature on the roadmap would ship next year, and you planned a project around it. You have a discount that was "for being an early customer." There's a connector to another tool you use that the vendor built as a favor.

None of that is binding. After an acquisition it's the easiest stuff to drop, often with no ill will at all. The new owner simply doesn't know it exists.

Make the list. Then send your account manager a short, friendly note: here's what we depend on, can you confirm in writing what's staying? You won't get commitments on everything. You will learn which answers come back quickly and clearly and which come back vague, and the vague ones tell you where to start planning.

Map every place the product touches your work

The contract tells you what you're owed. The integrations tell you what breaks.

Go through every place this product connects to the rest of your business: API calls your systems make, webhooks it sends you, nightly file drops, single sign-on and user provisioning, the report someone exports every Friday and pastes into a spreadsheet. For each one, note who on your side owns it and what happens if it stops for a day. The ones owned by "whoever set it up" are your real exposure. Our note on putting a name on every integration edge goes deeper on that.

Then test one real export. Not "we clicked download and got a file." Take the export, load it somewhere you control, and check whether the relationships survived: orders still attached to customers, parts still attached to assemblies, history still attached to records. If the export comes back flat or partial, you've just learned the most important fact about your leverage. The exit readiness scorecard is a quick way to score this across export, identity, runbooks, and running old and new side by side.

Then decide on what you found

By the end of the month you'll have something better than a feeling: the dates, the promises, the map, and a tested export. The decision usually takes one of three shapes.

Stay if the renewal terms are reasonable, the things you depend on came back confirmed in writing, and your export works. Set a reminder to check again in a quarter, because ownership changes take a while to show up in the product.

Renegotiate if the terms are open or the answers came back vague. You know your notice window now, so you can raise it on your schedule instead of theirs. Ask for a price cap, a longer notice period before API changes, or exit help written into the order form.

Start an exit plan if the export is weak, your critical integrations lean on something the new owner is likely to change, or the product was never a great fit and this is the push. An exit plan isn't a migration. It's knowing what you'd move to, how long it would take, and what you'd build to bridge the gap, so the choice is still yours when renewal comes around.

That last shape is often where we come in. Sometimes the work is rebuilding a fragile integration so it doesn't depend on one vendor's quirks, which is business process automation. Sometimes the honest answer is that the part of the workflow you've been bending an off-the-shelf tool around should be its own web application. And sometimes the answer is to stay and stop worrying. If a vendor you depend on just made the news, tell us what it touches and we'll help you work out which of those you're looking at.

Related work: Sutton|Place.