Integrating custom software Keene Systems builds with existing systems starts by mapping how data moves, which application owns each record, and where users need the information. For small and midsize businesses, the goal is usually to connect a new web or mobile application to established databases and workflows without disrupting daily operations. That can involve a SQL Server database, an older desktop application, FileMaker, or spreadsheets that still support essential work.
Key takeaways
A reliable integration preserves essential workflows by agreeing on data ownership, choosing a fit-for-purpose connection, and testing real exceptions before launch.
Integration choices at a glance
How integration works in an actual software project
Start with systems and workflows, not software names
Integration is the planned exchange of data and business actions between applications, with defined rules for ownership, timing, validation, and failure recovery. Before development, we identify the systems involved and trace a real transaction from the person who enters it to every application that uses it.
For a manufacturer, that might mean following a production order from a spreadsheet or desktop program into inventory, scheduling, and reporting. The team records which system creates the order, which one changes its status, and what happens when a part number is missing. A diagram of these flows is more useful than a list of product names alone.
Next, we inspect the available connection points: documented APIs, database schemas, file exports, and user workflows. The integration approach should respect the capabilities and limits of the current application. An older system with no supported API might need a controlled file exchange or a staged replacement rather than a fragile interface built around its screens.
Define data contracts and failure behavior
For each exchange, define the fields, formats, identifiers, and validation rules. A customer ID, for example, should not be matched by name alone if duplicate names are possible. The design should state how the software handles a missing ID, an invalid date, a duplicate order, or an unavailable destination system.
A practical sequence looks like this:
- Inventory systems and owners: Record each application’s purpose, technical owner, database, and business-critical users.
- Trace priority workflows: Follow representative records through entry, approval, fulfillment, and reporting, including exceptions.
- Specify the interface: Document field mapping, authentication, frequency, validation, and the system that owns each value.
- Build and test a narrow path: Connect one high-value workflow in a test environment before extending integration to other processes.
- Deploy with monitoring: Verify logs, error alerts, reconciliation, access controls, and a rollback approach before enabling production traffic.
Keene Systems’ article on SQL Server database design explains why sound data structure matters to a custom application. Integration work builds on that foundation by deciding how existing and new records relate, rather than assuming similarly named fields mean the same thing.
For regulated workflows, integration also has to fit the relevant rules and review process. According to the CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F), impacted payers are required to implement certain provisions by January 1, 2026, and have until primarily January 1, 2027, to meet the API requirements in the final rule.
What changes the scope, timing, and cost
The condition of the source systems matters
Integration effort is shaped less by the number of applications than by the quality of their interfaces and data. A documented API with stable identifiers is a different starting point from a desktop program that exports inconsistent spreadsheets or a database whose field meanings are known only to a former programmer.
Data quality work can become a substantial part of the project. Before moving records, teams often need to identify duplicates, normalize dates and units, reconcile status codes, or decide how to preserve historical values. If a legacy application stores a supplier’s address in several places, the new design needs a rule for which copy wins and how changes propagate.
The number of workflows also affects scope. Connecting customer records is not the same as coordinating approvals, inventory reservations, and payment status. Each additional workflow introduces its own permissions, exceptions, and acceptance criteria. Define the business outcome first, then prioritize the smallest set of exchanges that supports it.
Architecture and operational requirements add effort
An API connection, scheduled file transfer, or direct database integration carries different testing and maintenance needs. Authentication, network access, cloud hosting, backups, and response time requirements influence the architecture. So does the need to keep a mobile application usable when a device briefly loses connectivity.
Regulatory context can alter review and release steps. According to the FDA guidance on software changes to an existing device, the guidance will assist industry and Agency staff in determining when a software, including firmware, change to a medical device may require a manufacturer to submit and obtain FDA clearance of a new premarket notification (510(k)). That is a decision for the manufacturer’s regulatory process, not a conclusion to infer from software design alone.
For public-sector and compliance-sensitive environments, architecture review may cover custom and commercial components alike. The CMS Technical Reference Architecture applies to custom-produced as well as COTS products and services. The relevant environment and its requirements should be established before an integration design is finalized.
Pro Tip: Ask for a sample record map before approving an integration estimate. It should show source field, destination field, transformation rule, validation, and what happens when the source value is blank or invalid.
A provider should separate discovery, build, data cleanup, testing, deployment, and ongoing support in its scope. That makes it easier to see whether an estimate includes migration and reconciliation or only the interface code. Keene Systems’ custom software development process describes the value of defining project needs before implementation begins.
A checklist before connecting your systems
Bring evidence from the current workflow
A useful integration kickoff relies on actual artifacts, not assumptions about how a system works. Bring representative exports, screenshots, database documentation, and examples of records that users consider correct. Remove sensitive information from samples unless a secure sharing method has been agreed.
- Name each system and its role: Include the application, database, vendor or internal owner, and the business process it supports.
- Identify authoritative records: For customers, orders, inventory, and other key entities, specify which system creates and updates each record.
- Collect interface details: Note API documentation, authentication requirements, database versions, export formats, and any scheduled jobs already in use.
- Provide real exceptions: Include examples of duplicate customers, partial orders, discontinued items, and other conditions that routinely interrupt processing.
- Set timing expectations: Define whether information must appear immediately, within minutes, or in a scheduled daily transfer.
- Describe user access: Identify roles that can view, create, approve, or correct integrated records, including mobile and remote users.
- Define acceptance checks: Set concrete tests, such as a record arriving with the correct identifier and status, and an error appearing when required data is missing.
- Plan for continuity: Decide how staff will work during deployment and who approves a rollback if the integration behaves incorrectly.
- Assign technical ownership: Identify who can approve database changes, provide test access, and maintain credentials after launch.
If an application is being replaced, distinguish migration from integration. A desktop-to-web conversion may need historical records imported once, while a system that remains active needs ongoing synchronization. Treating both as the same task creates unclear ownership and unnecessary interfaces.
Pro Tip: Select test cases with both normal and failed outcomes. A successful order alone does not prove the integration handles duplicate submissions, an unavailable database, or a rejected field correctly.
For small businesses that have lost their programmer, preserve access to source code, deployment instructions, database backups, credentials ownership, and a list of scheduled tasks. Those materials help a new team determine what the current system actually does before making changes.
Ready to map your application connections and priorities? Talk with our software development team.
Our perspective on integration
Keep the business rules visible
We approach integration as a software architecture and workflow problem, not simply a matter of connecting endpoints. A technically successful transfer can still produce bad results if two applications interpret order status, inventory quantity, or customer identity differently. We advise documenting those meanings before implementation and keeping the mapping available to the people who maintain the application.
We also avoid replacing a working system just because it is old. If a business can retain a stable application and connect it safely, an integration may be the more controlled step. If the software has no reliable data access, creates duplicate work, or cannot support necessary changes, a web application replacement or staged migration may be more appropriate.
The right decision depends on system condition, workflow risk, and the cost of continued workarounds.
Our work spans custom web applications and technologies such as ASP.NET, SQL Server, FileMaker, React, Java, and PHP/MySQL. That range matters when a new application must coexist with an existing stack. It does not mean every system should be connected directly; sometimes an intermediate service or a deliberate data migration is easier to support.
EPA’s CROMERR overview reports that, in 2022, about 90 percent of applicants pursued off-the-shelf solutions for at least part of their system. That fact supports a practical point for system planning: a business often needs to consider how purchased software and custom components fit together, rather than treating the choice as all-custom or all-commercial.
When to bring in an integration specialist
Get help when the workflow crosses technical boundaries
Bring in a specialist when important work depends on manual re-entry, a programmer’s undocumented knowledge, inconsistent spreadsheets, or a legacy database that must exchange data with a new web or mobile application. A specialist is especially useful when a system has no API, several applications update the same records, or users report mismatched totals and statuses.
Prepare a workflow diagram, sample data with sensitive details removed, a list of applications and versions, and the business rules users follow when records conflict. Include any known access restrictions, downtime limits, security requirements, and deadlines. If a former developer has left, gather source code, database backups, hosting details, and deployment notes before making production changes.
A capable provider should explain the proposed data flow, ownership of records, exception handling, testing method, deployment sequence, and ongoing maintenance responsibilities in plain language. For software subject to federal procurement rules, the contract may matter too: according to 48 CFR § 1539.2071, Contracting Officers shall use clause 1552.239-71, Open Source Software, for all procurements where open-source software development or custom development of software will be required.
For Department of Defense commercial software requirements, the general rule in 48 CFR § 208.7402 states that departments and agencies shall fulfill requirements for commercial software and commercial software services, such as software maintenance, in accordance with the DoD Enterprise Software Initiative (ESI). The contracting context should be understood before project commitments are made.
Frequently asked questions
What is the safest way to connect a new application to an old database?
Start by confirming the database owner, schema, backup process, and supported access method. Prefer a documented API or a controlled integration layer when the existing application provides one. If direct database access is necessary, define read and write permissions narrowly, agree which system owns each field, and test against a copy of production data before making changes to live records.
Should a business integrate its legacy desktop application or replace it?
Integration fits when the desktop application remains reliable and exposes usable data through an API, database, or repeatable export. Replacement is worth evaluating when the system blocks essential workflow changes, depends on unsupported technology, or forces users to re-enter information. A phased approach can preserve access to historical records while moving active work into a modern web application.
How do you prevent duplicate or conflicting data?
Define stable identifiers for each key record and establish an authoritative source for every field that can change. Then specify validation, duplicate detection, update timing, and conflict resolution. Test realistic cases such as two systems changing an address or an order being submitted twice. Logs and reconciliation reports help users find exceptions instead of silently accepting mismatched records.
What should an integration project include after launch?
Plan for monitoring, error alerts, access and credential management, backups, and a named owner for each interface. The team should know how to identify a failed transfer, retry it safely, and confirm that a retry will not create duplicate records. Maintenance should also account for changes to APIs, database schemas, hosting, or business rules, with testing before those changes reach production.
How Keene Systems helps connect your software
Build around the systems you already rely on
Keene Systems is a veteran-owned custom software development company founded in 1987, with a team of more than 50 web and mobile developers. We work on tailored applications that support business operations, including web application development, SQL Server database design, ASP.NET development, FileMaker Pro development, mobile application development, and application integration.
The appropriate approach depends on the systems, data, and workflow involved. Our work can include replacing spreadsheet-based processes, modernizing a desktop application, designing a new application around an existing database, or planning a staged transition. For a closer look at the role of database structure, see our guidance on SQL Server database design for custom software.
Relevant capabilities include:
- Application integration: Define and build connections between business applications and data sources.
- Legacy system modernization: Move essential workflows toward maintainable web applications where appropriate.
- Database design: Organize SQL Server or MySQL data to support consistent application behavior.
- Ongoing maintenance: Support changes and fixes after deployment as systems and business rules evolve.
Tell us what needs to connect and where the current process breaks. Discuss an integration project with Keene Systems.
Conclusion
The first step in integrating custom software Keene Systems develops is to document one high-value workflow from the original data entry through every system that uses the record. Mark who owns each field, how often it must update, and what users do when the data is missing or contradictory. That evidence determines whether an API, scheduled exchange, database connection, or staged replacement fits the situation.
Avoid starting with a broad promise to connect everything. A scoped workflow, defined test cases, and an agreed recovery plan give your team a sound basis for estimating the work and protecting daily operations. When you are ready, gather a few representative records and system details, then use them to shape a practical integration plan.
Sources
- 15 CFR § 791.303 – Prohibited covered software transactions.
- CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F)
- 15 CFR § 791.308 – Exemptions.
- Deciding When to Submit a 510(k) for a Software Change to an Existing Device | FDA
- 48 CFR § 1539.2071 – Contract clause. | Electronic Code of Federal Regulations (e-CFR) | US Law | LII / Legal Information Institute
- Overview for CROMERR | US EPA
- CMS Technical Reference Architecture | CMS Information Security and Privacy Program
- 48 CFR § 208.7402 – General. | Electronic Code of Federal Regulations (e-CFR) | US Law | LII / Legal Information Institute