What "one IT contact" means in practice for a multi-site rollout
A plain account of the single IT contact a multi-site data rollout needs: what that person does, where their time goes, and why one named owner moves faster than a committee.
When we list what we need from a design partner, one line tends to draw questions: one IT contact at one site. Operations leaders read it and wonder whether it means a full-time hire, a project team, or a standing weekly meeting. It means none of those. It means one person with enough access and enough authority to let us in, answer questions, and make small decisions without calling a meeting.
What the requirement actually says
Our design-partner criteria are short. You run more than one site, and those sites keep their data in SQL Server, MongoDB or Postgres. You have one IT contact who can get us access to a single site to begin with. And you are happy to start small: one site, one set of tables, something useful in your hands early, then the rest at your pace.
The IT contact is the thread that ties the other three together. We cannot start at a site without someone who can open the door, and we cannot keep a rollout moving if every question has to travel through several inboxes.
What the contact does at the first site
The first site is where most of the contact's effort goes, because it is where the decisions are made that every later site will reuse. The work falls into a handful of steps.
- Provide a place to run a small piece of software inside the site's own network, on the site's own hardware, behind its firewall.
- Arrange database access for it, limited to what the business is willing to share. The software touches only what that access permits.
- Choose, with the business, which tables (the named sets of rows a database keeps, such as orders or stock levels) are worth sending, and rank which matter most.
- Confirm that the site may send data out to the central store. The software only sends data out; nothing reaches back in to the site.
- Tell us about the site's rhythm: when it is busiest, when maintenance happens, and who to call if something looks wrong.
None of this involves changing the warehouse system itself. Nothing at the site is replaced or rewritten, which is usually the first thing a cautious IT team wants to hear.
What redfly does
We set the service up at the site together with your contact. The rollout tool is driven by a person throughout; it is not something that runs on its own. Once it is running, the service carries rows that are added, edited or deleted, not just new ones.
If the link drops, changes wait at the site and resume from where they stopped, table by table. If the site's machines are busy, the service holds back.
Changes are compressed and encrypted per site before they leave, and every row arrives stamped with the site it came from. Delivery is at-least-once, which means a change may occasionally arrive twice, and it is reconciled on arrival.
The central copy is current to within a couple of minutes. Your team builds the reports and any portal on top of it, with our advice and tools; we supply the data and the support.
How much of their time it takes
We will not put a number on it, because it depends on how the site is run, how quickly access requests move internally, and how many tables the business wants. What we can describe is the shape.
- Early on, the contact is busiest: arranging access, agreeing the tables, and answering our questions as the first site comes up.
- Once data is flowing, their role shifts to being reachable. They hear from us when something at the site needs a decision, not on a fixed schedule.
- Each new site needs its own setup, so the contact is involved again for access and site details. It is the same rollout each time, not a fresh build, so later sites usually ask less of them than the first.
- Adding tables later is a setting, but someone still has to decide what to add and check it. That is a small task, and it is still a task.
The honest summary is that this is part of a job, not a job, and that the load is heaviest at the start.
Why one owner beats a committee
A committee feels safer, because more people have seen the plan. In practice it slows every step down. A question about which tables to share becomes a meeting, and decisions drift because nobody is sure whose call it is.
A rollout moves at the speed of its slowest approval.
One owner changes that. They know the site, they know who to ask, and they can say yes to small things on the spot. When a larger decision is needed, they know who holds it and can bring back an answer.
The business still has oversight; it simply flows through one person rather than around a table. There is a second benefit, too. The first site sets the pattern for every other site, and a single owner carries that pattern forward.
When the fourth warehouse comes on, the contact already knows what access looks like, which tables matter, and what the first sites taught everyone.
Where redfly fits
redfly supplies the sync that carries each site's changes to one central copy, current to within a couple of minutes, and sets up each site with your contact. Your IT contact opens the doors, and your team builds the reports on what arrives.