Closed Systems Become Growth Ceilings

Ask your developers what it would take to show a customer their own order status in a portal. The portal is a week of work. Getting the status out of the system that holds it is the project, and that answer is why this has not made it onto a roadmap.

A system can run the company perfectly and still cap what the company is able to sell next. 

The obvious fix is to build the API and move on, and building it is also the moment the system stops being closed, so everything that was safe because nothing could reach it now depends on rules your team has to write. 

Writing those rules before the connection exists costs a meeting. Writing them after an incident costs considerably more.

‍

When does a closed system become a growth ceiling?

A closed system becomes a growth ceiling at the moment the business needs it to participate in something it was never built to participate in.

The trigger is usually specific and dated:

• A customer asks for self-service status and the portal cannot read the record
• A partner asks for an API and nothing in the stack can issue one safely
• An acquisition closes and two platforms hold overlapping customers with different IDs
• A regulator asks for an audit trail the system does not keep
• A new product needs pricing logic that lives inside a screen nothing can call
• Finance needs a number that only exists after two files get exported and joined by hand

The old system did not fail at anything. 

The gap is between what it was built to do and what the business committed to next, and that gap shows up as a roadmap item with no owner and no start date.

‍

What are the risks of exposing a legacy system through an API?

The risk of exposing a legacy system through an API is that the connection becomes the easiest path into everything behind it, which is why it needs the same controls as the system it reaches.

Between August 8 and 18, 2025, attackers used compromised OAuth tokens from the Salesloft Drift application to reach Salesforce instances at more than 700 organizations, a campaign Google Threat Intelligence and Mandiant disclosed later that month. Salesforce was not breached. 

Those companies were reached through a third-party connection they had each approved, and the tokens that made the integration work are the same tokens that made the theft work. Cloudflare, one of the affected companies, said it believed the threat actor "intended to harvest credentials and customer information for future attacks."

Akamai's 2026 study found that 87% of organizations had an API security incident during 2025, with the average organization absorbing 258 API attacks a day against 121 the year before.

You are the one who approves a connection like that, and the approval usually lands before anyone has written down what it can reach. 

Go list the integrations holding standing access to your core system right now, including the ones a vendor set up for a team outside IT. That list is your actual perimeter.

‍

What should you decide before exposing data from a legacy system?

Before anything reads from the old system, your team should have written answers to ten questions, and those answers belong in the spec rather than in the integration code.

1. Which system owns each record, and which one wins a conflict
2. Which users and which services can see which fields
3. Which connections are read-only, and which can write back
4. Which writes wait for a person
5. Which data never leaves the system, whoever asks
6. What gets logged, and who is allowed to read the log
7. How a failed sync is detected, and who hears about it
8. What happens to in-flight work when the connection drops
9. How long a credential lives, and what revokes it
10. Who revisits all of the above when the workflow changes

Those are business decisions. 

One meeting with operations, legal, and whoever owns the data covers a given connection, and most of the answers carry to the next one. 

The version that takes months is the one done after the fact, when the connection already exists and three teams have opinions about who broke what.

‍

How do you decide which system is the source of truth?

The source of truth for a record is the system where a person changes it on purpose, and every other copy should be downstream of that one.

Take a customer address. 

Sales updates it in the CRM during a call, billing updates it in the ERP when an invoice bounces, and the customer updates it in the portal. All three are real edits made by real people with good reasons. 

Without a written rule, the last sync wins, which means the correct address is whichever system happened to run most recently.

Pick the owner field by field. The CRM may own the contact and the ERP may own the billing address, and both can be right as long as the rule exists somewhere other than in a developer's memory.

Write it into a one-page table listing the field, the owning system, who can change it, and what happens to the copies. 

It takes an afternoon, it settles arguments that otherwise return every quarter, and you know it worked when two people from different departments give you the same answer.

‍

How do old and new systems coexist during a migration?

Old and new systems coexist during a migration by running in parallel with one designated as authoritative for each record, for a period that has an end date on it.

Most of the risk in a migration sits in this window. 

Both systems hold data, both accept writes, and the business is depending on a sync that has to be right every time and gets no attention when it is. 

Decide up front how drift gets detected, how often someone compares the two, and what the rollback looks like if the new path is wrong.

Put an end date on the parallel period before it starts, because a migration without one becomes the architecture, and every integration after it has to account for both systems.

For ComplianceDashboard we led a complete platform re-architecture, replacing a twelve-year-old system with a custom compliance management platform, and every release was coordinated to protect existing client data and minimize disruption. 

The platform now sends over 20,000 emails per week. Lesley Marling, VP at ComplianceDashboard, says the team "took the time to explain complicated features in a way that allowed us to make informed decisions."

We believe that business is built on transparency and trust, and that good software is built the same way, which during a migration means anyone can say which system is authoritative today.

‍

What should you check before the first integration goes live?

Before the first connection goes live, walk one record from the old system to the new one and watch what happens to it at every hop.

Follow a customer, a claim, or a work order, and write down:

• Every place it gets copied
• Every place a field gets transformed or truncated
• What the receiving system does with a value it does not recognize
• What happens to the record if the connection drops mid-transfer
• Who finds out that it failed
• Which copy you would trust if the two disagreed tomorrow

That walk surfaces the decisions that were never made, and it is faster than the meeting where your team tries to imagine them.

AI belongs well after this. 

A model that summarizes a claim or routes an exception needs a source of truth, a permission model, and a record of what it touched, and a system that cannot safely hand a field to a dashboard is not ready to hand one to a model.

Pick the request your team has been putting off scoping and write down the ten answers for it this week. 

The build is rarely the hard part.