ePublishing. Migrated mid-cycle.

ePublishing is a US publishing-technology company headquartered in the Wilmington, Delaware corridor with a working office presence stretching back to Chicago. For the better part of two decades the company has built the software that runs the back-office of US trade and B2B publishers. Subscription engines that charge readers. eCommerce engines that sell digital editions. Content management systems that move a story from the editor's queue to the front page in under a minute. None of it is glamorous. All of it is load-bearing for the publishers who depend on it.

If you have ever read a national magazine online and paid for a subscription without thinking about the plumbing behind that paywall, there is a strong chance the plumbing was built or maintained by an engineer working in ePublishing's ecosystem. The work pairs old-internet rigor with newer requirements around personalization, ad targeting that respects privacy, and global content delivery. It is not a fashionable category. It is a profitable one, with multi-decade customer relationships that few SaaS startups will ever build.

By the time ePublishing approached us, the company had a settled engineering culture and a clear point of view on how India hiring should work. India was not a cost-arbitrage afterthought. India was a primary engineering location for product surface-area that mattered: the subscription backend, the publisher admin tools, the motion design system used across the company's marketing surface. The team's instinct was correct. India offers a deep pool of mid-to-senior product engineers and motion designers who have been building for global audiences for fifteen years.

What ePublishing did not want was to set up its own Indian private limited company. The math is well-rehearsed at this point. An entity in India that supports under twenty people costs more in compliance and books-keeping than it saves in EOR fees. It also slows the timeline from 'we want to hire' to 'first salary paid' by ninety days minimum. ePublishing's leadership made the right call: stay on an Employer of Record while the team grows past the entity break-even.

The problem was the Employer of Record they were on did not understand publishing engineering and did not understand India compliance at the depth ePublishing needed. The previous provider was a global EOR with a thin India operation that sub-contracted everything below the surface. Compliance questions waited days. UAN portability questions had no answer at all. The Net-15 USD invoice would arrive with line items that did not reconcile to headcount. ePublishing had outgrown the provider by month five.

That is the company that found us in early June 2025. A six-person India team. A history of being burned by a reseller. A clear-eyed read on the math. And one technical lead at the US headquarters with a strong opinion about what an Employer of Record should look like: same entity owns the registration, same team answers the email, same documentation at every audit.

There were three pressures stacked on top of each other when ePublishing reached out. The first was the obvious one: the previous Employer of Record was not delivering. Compliance questions sat unanswered for a week. Replies, when they came, came from someone different each time. There was no named person on the file. The technical lead at ePublishing had given up trying to learn the names because the names kept changing.

The second pressure was UAN continuity. India's Universal Account Number (UAN) is the lifelong identity that ties an employee's Provident Fund record across every employer they ever have. Mid-career engineers have multi-decade PF balances tied to their UAN. If an EOR transition is botched and a new UAN is generated by accident, the employee can spend twelve months pulling balance transfers and filing grievances. The previous provider had not given ePublishing's team confidence that UAN continuity would be respected on exit. The fear was not theoretical. It was a fear of personally embarrassing six engineers whose long-term financial records the company controls.

The third pressure was timing. ePublishing's payroll cycle ran on the last day of every month. The technical lead wanted the migration to happen between payroll cycles, in one cleanly bounded window. The previous EOR would issue June salary. The new Employer of Record would issue July salary. Nothing in between. No double-payment risk. No skipped month. No goodwill spent on six engineers wondering why their bank account looked wrong.

On top of all of that, ePublishing had a senior Motion Designer pending an offer. She had been waiting for the EOR question to be resolved before she would accept. Her current employer had counter-offered. ePublishing's window to land her was approximately four weeks. A botched migration would also be a lost senior hire.

Sagar Chainani took the first call with the Technical Lead on a Tuesday afternoon. By Friday the MSA was signed. The first thing Versatile did was put a named compliance manager on the file and write a one-page migration plan that listed every UAN, every PF balance, every gratuity accrual, and every device serial that would change hands. The plan was specific enough that the Technical Lead forwarded it to the previous provider with a single line: here is what continuity looks like; please match this on your exit.

That email was a small moment. It was also the moment ePublishing understood the difference between an EOR that resells someone else's India operation and an Employer of Record that runs the operation itself.

ePublishing's migration window was the last week of June 2025. The previous EOR would issue June salary on the 30th. Versatile had to be ready to issue July salary on the 31st. Every onboarding task had to slot inside that bounded window.

What follows is the actual five-business-day Employer of Record onboarding sequence we ran. Versatile keeps this SLA across every new hire and every migration. The pattern is documented internally as 'first-five' and it has not been broken since Versatile was founded.

All six specialists moved across the same week. The Technical Lead at ePublishing received a single status email at end-of-week-one with one line of progress per person and the document references. Nothing slipped. July salary was credited on time. The previous EOR did not have to wave anyone back across, because nobody had been left behind.

Versatile's previous EOR comparison data on this is documented. The global EORs we have replaced typically take fourteen to twenty-eight business days for a first hire. They take longer for migrations because the sub-contractor on the other side has to be scheduled. Five business days is a real number that holds because the entity, the compliance team, and the payroll pipeline are all the same operation under one roof.

Most Employer of Record marketing collapses compliance into a single bullet that reads 'we handle compliance, PF, TDS, etc.' The shorthand is fine on a homepage. It is useless if you are the Technical Lead at ePublishing trying to understand what your liability surface looks like in India.

The honest version is that India statutory compliance is twenty-two distinct items that fire on different calendars at different rates depending on the state, the salary band, the family situation of the employee, the financial year, and the company's organisational age. Below is what Versatile actually handles, item by item, every month, on behalf of ePublishing's six specialists.

The reason this is twelve items and not three is that India has not collapsed its statutory framework into a single labour code yet. Four labour codes were passed in 2020 and 2022 (Wages, Industrial Relations, Social Security, Occupational Safety) but the rules have not been notified at the central level for most states. Until they are, we file against the old framework. Versatile's compliance team tracks the central and state notifications weekly. The day the labour codes are notified, our process documentation will change overnight. ePublishing will not see the cost or the disruption. That is the work.

Across eleven months and six specialists, ePublishing has received zero compliance notices, zero rectification orders, and zero penalty assessments. That is not luck. That is what 'India-native Employer of Record' is supposed to mean at the operational layer.

Eleven months in, the operational metrics at ePublishing's India engagement look like this:

The most useful framing for an Employer of Record is operational time freed for the customer's leadership. If a Technical Lead is spending ten hours a month chasing the EOR for compliance answers, they are not building product. If a finance team is spending half a day reconciling FX losses against an INR invoice, they are not closing the books. The cost of these distractions is rarely modelled, which is why most EOR pricing comparisons miss the point. Versatile's pricing is somewhere in the middle of the India-native peer band. The cost-of-ownership including operational time is the part that meaningfully diverges in our favour.

ePublishing's Technical Lead has documented this in her internal retrospective. The retrospective is not public. The shorthand version she has shared externally is the testimonial below, and the recommendation she has made to two other publishing-technology peers since.

Every engagement teaches Versatile something about the depth of the operational discipline an Employer of Record needs to hold. ePublishing taught us three things specifically.

First: mid-cycle migrations are not edge cases. They are the most common engagement shape we will see across the next three years, because the first generation of global Employer of Record products are at the point in their lifecycle where customers are evaluating renewals. We have rebuilt the migration playbook around UAN continuity and PF transfer mechanics. The Technical Lead at ePublishing wrote half of the second version with us.

Second: USD invoicing is structural, not marketing. Most India EORs are not equipped to receive USD wires. We thought of this as a competitive advantage previously. We now think of it as table stakes for any US customer who has been burned by FX losses on an INR-invoiced India EOR. Our website explains the mechanic explicitly because the alternative is letting prospects discover it on their own quarterly close.

Third: the named compliance team is the brand. ePublishing's Technical Lead knows three of our team members by name. Those three names mean more to the relationship than my own as the founder. We have moved Sagar's name out of customer-facing support narrative across the website. The team is the product. The team is what holds the four-to-six-hour TAT month after month. The team is what the case study should celebrate.

If you are a US publishing-technology company, a SaaS company with a content-engineering team, or any product business with India engineering on a previous global EOR that has stopped meeting your bar, the mid-cycle migration pattern is the easiest engagement to evaluate.

What it looks like in practice: a thirty-minute call with us to map your current state. A two-page migration plan from us inside seventy-two hours. An MSA in week two. First payroll on Versatile in week four. Zero employee-facing disruption.

What you should expect from us before you sign anything: a one-page plan with every UAN, every PF balance, every gratuity accrual, and every device serial. If a provider cannot give you that document inside three working days of the first call, they do not have the India operation to back the work.