PLATE IIMaking disparate systems share data — legacy to cloud, POS to accounting, database to API.

The practice

Integrations

We integrate systems that were never designed to talk to each other, so they can share data.

Most of the work we are asked to do lives in the segment between two systems. One of them is usually older than the other, and neither was built with the other in mind.

That gap is where an integration earns its keep — not by replacing either system, but by making the pair behave as though someone had planned them together.

Create a data feed from your legacy software into new cloud-based services
Push sales and inventory information into an accounting system
Open an old database up as a set of services other systems can connect to
Push data to internet-accessible reporting systems
Pull data out of the system you are leaving and into the one you are adopting
Create connections between your system and new hardware

Questions we are actually asked

Can you integrate a system you did not build?

Yes — that is the usual case. Most integration work involves at least one system nobody on the project wrote, often with no supported API.

What if the old system has no API?

We open the existing database up as a set of services, which lets other systems connect without the legacy application having to change.

Do you handle hardware as well as software?

Yes. Creating connections between an existing system and new hardware — scanners, printers, payment terminals — is part of the same work.

Start a conversation

Also in the practice

Customization — Plug-ins and utilities for Retail Pro 8, 9 and Prism — and migration of the customizations you already depend on.
Porting to new technologies — Legacy systems are reliable right up until nobody is left who can work on them.
Web and social applications — Something more involved than an informative site with a contact form.
Project management — New projects, and projects that had gone completely off the rails.