Interview with Pritam Khedekar, IT and Enterprise Retail Infrastructure Professional

Interview with Pritam Khedekar, IT and Enterprise Retail Infrastructure Professional

(Featured) - Khedekar details the role of discovery, rollback, automation and PCI-focused coordination for retail and QSR fleet migrations.

Interview with Pritam Khedekar

Edited by Haley Spracale, Editor at Featured News · Nov 6, 2026

As a Senior Applications Consultant in IT services with experience in point-of-sale systems, server migration, and infrastructure management, what kinds of retail technology challenges do you help organizations solve?

In my career, I have encountered many common problems that were handled with workarounds, with no permanent solutions put in place. For example, broken OS images on point-of-sale (POS) systems across the fleet were handled with workarounds on a per-incident basis. User onboarding and offboarding were poorly managed, without making use of the enterprise tools the company was already paying for. Application deployments were not standardized and overlapped with one another, so they, too, were handled with workarounds on a per-incident basis.

No proper system compliance audit data was maintained, and endpoint compliance was not measured regularly, so vulnerable systems went unnoticed. No minimum compliance requirement was defined as a security baseline, and teams mostly relied on antivirus software that was poorly or barely managed. There was no business continuity process, no proper RACI (Responsible, Accountable, Consulted, Informed) matrix, and no maintained process knowledge base.

Whenever I join a client, I first evaluate security, scalability, risks, and areas for improvement, including opportunities for automation. I evaluate many factors, including the observations mentioned above and anything else I observe while personally going through the knowledge transition.

What career experiences led you into supporting complex application and infrastructure changes for retail environments, including POS and in-store systems?

My recent assignment with a large North American quick-service restaurant (QSR) chain gave me the chance to work with application deployment and point-of-sale (POS) maintenance pipelines that were very well built but still complex.

One of the most complex problems I have solved involved POS systems in the chain’s stores in Québec, Canada. The POS systems were deployed with an operating system image designed for U.S. stores, and French-speaking store staff found it hard to adapt. The POS application also ran in English because the software vendor had hard-coded it to follow the system language by default.

That meant extra, unnecessary work for the deployment team on every new system: installing the language packs on site, waiting for them to finish, launching the POS application to check the language, and validating each function to confirm that it worked in Canadian French.

I came up with an out-of-the-box solution. I developed a Canadian French language package that the deployment policies run before any other package is installed on a newly deployed POS system. The package changes the system language, then logs and validates that it is set correctly. Because this package is now enforced specifically for Québec stores, the extra on-site work and the language issue are permanently solved.

When a retail or QSR chain identifies end-of-life POS terminals, back-office servers, or store PCs, how do you turn that need into a retirement plan that protects trading hours?

Each store system has its own role and usually its own hardware. POS terminals are touchscreen devices from many manufacturers, with models suited to different QSR operations. Store PCs are standard office computers, thin clients, or laptops. Back-office servers are mostly blade servers mounted in racks in server rooms. Every product has its own lifecycle timeline, so the retirement plan is different for each role.

POS devices take the longest because of their peripherals: the customer display that shows prices as items are added, the card reader for rewards or payment cards, cameras for drive-thru, scanners, receipt printers, and sometimes label printers. A new model or brand usually means new peripherals. Before anything else, the hardware goes through penetration testing by the security team. Then we update the custom OS image, add device profiles, drivers, and customization scripts, and run unit testing. Next, we build a lab store on a desk that works like a real store, followed by QA automation and certification. For POS alone, certifying a new device can take up to 26 weeks.

Store PCs and back-office servers are faster because they don’t make sales, and most QSR back-end applications are software services that don’t depend on specific hardware. Store PCs become a bottleneck when manufacturers keep retiring recent models and supply runs short. Lifecycle dates aren’t the only trigger for a retirement plan. Product availability in the market matters just as much.

To protect trading hours, replacements are mostly done overnight. The new devices and supporting hardware are shipped to the store ahead of time, and staff secure them in the back office. During the pilot, support partners and SMEs visit the store and replace only half the devices. For example, if a store has six systems, they replace three and leave three running on the old hardware. Once we have observed the new devices and applied any hot fixes, the remaining three are scheduled for replacement. Pilots can take months, depending on the size of the business, but once the pilot phases succeed, production stores are usually installed in one visit.

Drawing on your experience with infrastructure inventories and security standards, what discovery work is most important before a chain schedules its first store-system retirement?

Before the first store is scheduled, I check a few discovery items. The first is supplier commitment: a written commitment from the vendor regarding device availability, or compensation if the vendor fails to deliver. The second is the device supply in numbers, meaning the quantity that has to be secured before starting. In my experience, most small and midsize businesses start with about 500 units, and some large chains start with 2,000. The third is an accurate CMDB. The configuration management database, usually hosted in the support ticketing system, has to reflect what is really in each store.

Stores need to be prepared, and staff need to know what is coming. There also needs to be a RACI matrix (Responsible, Accountable, Consulted, Informed) and a clear backout or rollback plan. For example, if an install fails at a store, the plan says who will support each component, who will be informed, who will confirm a successful install, and with whom the information will be shared.

Finally, I check for any payment infrastructure changes, the store geography for both logistics and regional languages, and a plan and roster of the participating stores.

You have emphasized using real users in pilot waves; how do you choose pilot stores and frontline participants that will reveal the risks a lab test can miss?

Pilot stores are often those close to the brand’s headquarters or the support partner’s offices, or near the partner’s technical depot, where spare hardware and devices are stored.

A pilot store is also often one that is less busy on certain days—for example, a store inside a university that is quiet on weekends, a store near government offices that is quiet on weekends or even Fridays, or a store on the outskirts that usually does less business. If an issue comes up that requires a hotfix, these are the stores where it has the least impact. That is mostly how businesses choose pilot stores.

Pilot stores reveal risks and issues because they process real transactions. They serve real customers and have to manage and deliver real orders. That real-world operation is what makes a pilot succeed in a way a lab cannot.

The frontline participants are mostly experienced store employees who understand what a pilot means because they have been through one before. These may include the store manager, experienced crew members, and shift leads. They are briefed on clear actions before the pilot starts.

What does a well-designed overnight cutover runbook look like for retiring store technology, and which checkpoints help the team decide whether to proceed or stop?

A good overnight cutover runbook covers three stages, with a clear decision point in the middle.

Before the night, device availability is confirmed, along with the delivery date, time, and quantity, using a delivery receipt. Store staff confirm that the packaging has not been tampered with, and the installation team is briefed on the on-site work. After-hours access is arranged for technicians, usually through the store manager or senior staff, and technicians bring all required tools and utilities.

During the install, support teams are on call to provide help and support post-installation validation: the service desk, payments support, POS application front-end and back-end support, and the POS system image engineering team. Technicians start the work and call for help as soon as they encounter a problem. Then comes the proceed-or-stop checkpoint, often called “go or no-go” by technology departments. If the issue can be fixed, the appropriate team applies a hotfix and documents the fix in a knowledge base article (KBA). If the problem cannot be solved, or there is no known fix, we roll back the change, restore the old systems as they were, and document the problem in the issue tracker.

After the install, the morning shift manager or senior staff take the handover from the technicians. They check that all required peripherals are attached and run a test transaction on the new systems if there are any doubts. All teams perform a sanity check after the work is complete, followed by a final call where everyone confirms that the activity is complete. The old hardware and peripherals are shipped back to the technicians’ depot.

In a fleet migration, what rollback capability should be in place before a store’s legacy POS or back-office system is taken offline?

Several layers of rollback are in place before any legacy system is fully taken offline.

First, stores always have at least two POS systems, so they can keep trading and generating revenue with the minimum resources if a new POS system turns out to be faulty. I’ve seen experienced staff handle a morning rush with fewer registers without customers noticing. They are skilled and know how to manage these situations.

Second, as I mentioned earlier, only 50% of a store’s systems are replaced at first. The other 50% remain on legacy hardware and keep the store running if the new systems fail. Those legacy POS systems are replaced only once management and the technical program managers (TPMs) are fully confident, based on the order and revenue data generated by the new systems in those stores.

Third, the removed legacy systems are not scrapped right away. They are disassembled and packed in their shipping boxes so they can be taken out and used again if needed. That is rare because, in my experience, a hotfix resolves almost every issue.

Beyond that, rollback support includes sending technicians overnight or on the spot, hotfixes, remote support, the service desk, and SMEs for the POS application, hardware, peripherals, and engineering.

How have automation tools such as PowerShell, monitoring platforms, or endpoint-management controls helped make large-scale store migrations more repeatable and less disruptive?

Every QSR company I’ve worked with uses its own set of tools to automate tasks that are script- or software-based and don’t require anyone to physically touch a device. These are mostly PowerShell, Bash, and batch scripts, and sometimes custom-built executables (.exe files).

My past migrations went smoothly largely because of custom, in-house automation that can replicate policies, apply hotfixes, and provide remote access and troubleshooting. My remote package deployment approach is a good example of policy-based automation removing on-site work, like the Québec language package I described earlier.

Whenever we migrate a group of stores, I add those stores to a dedicated monitoring group that watches for failed transactions, system failures, availability, and performance. Any of those indicators gets flagged, so we know right away if a store has had or is experiencing a failure.

Every endpoint management tool is different, but the methods, deployment schedules, and precautions are very similar because most businesses use similar platforms provided by OEMs, service providers, and managed service providers (MSPs).

Looking back on real fleet migrations, what is one lesson about coordinating store operations, support teams, and security or compliance requirements that retail and QSR leaders can apply before their next rollout?

The lesson I’d share is that coordinating store operations is not difficult if you have a blueprint of responsibilities and a proper plan built around it, with the responsible teams and people kept consistent throughout.

A blueprint covers the high-level plan, the departments involved, and their standard operating procedures (SOPs).

A major part of that blueprint is PCI compliance (the Payment Card Industry Data Security Standard), the security and compliance requirement that QSR brands focus on most. It is a broad topic at the blueprint level, but it becomes very detailed when each team or partner follows it during store operations. It starts with network and infrastructure security, then data security—whether that’s store, business, employee, or customer data—and finally, payment encryption and payment gateway security.

The go-ahead usually comes from leadership, based on its view of how to grow or secure the business. At ground level, the picture can be different: each team has its own motivations, KPIs, and responsibilities in store operations. It’s like a row of dominoes standing next to each other. If the blueprint isn’t followed and one link falls, the rest collapse one by one in no time.

About the expert

Pritam KhedekarIT Professional, Enterprise Retail Infrastructure

This story was produced by Featured and republished with permission. Experts featured here are members of Connectively, Featured's expert network.