Offshoring Examples: What Apple, IBM, and JPMorgan Did Right

The most useful offshoring examples aren’t the abstract case studies in McKinsey reports. They’re the specific companies you’ve heard of, with names you recognize, that bet their operations on a team in another country and either got it right or got it wrong. For the policy side, see why Trump’s war on IT outsourcing keeps losing in the courts. For the US side of this, see which companies actually outsource to the Philippines and what the lists get wrong.

This post is the rundown of the offshoring examples worth knowing about. Six companies that made offshoring work, three that didn’t, and what the difference was each time.

I’ve spent the last 20+ years building and running offshore engineering teams across four companies of my own, so this is also where I’ll add what I’ve learned about why some of these examples ended in acquisitions and others ended in lawsuits. The model matters more than the geography, and that’s what the patterns below show. The specific examples keep changing too, which is why it helps to track how offshore development is evolving as AI reshapes the work.

If you want the broader frame for how offshore developers fit into a high-functioning engineering organization, that’s what my book Product Driven covers in depth.

What “offshoring examples” actually covers

Offshoring means moving part of your operations to a team in another country, while keeping ownership and direction in-house. Manufacturing, customer service, finance, IT, software development: all of it can be offshored, and the examples below span the full range. I’ll call out which model each company used (offshoring through a captive subsidiary versus offshore outsourcing to a third party) because the model is usually what decides the outcome.

For the offshore-versus-onshore tradeoff in software specifically, see the 10 real benefits of offshoring. For when offshoring is the wrong move, see the signs you’re ready to outsource software development.

6 successful offshoring examples

1. Apple and Foxconn in China

The most famous offshoring example in business history is Apple‘s manufacturing partnership with Foxconn, the Taiwanese contract manufacturer that runs the Chinese factories where iPhones, iPads, and most Apple hardware get assembled. Apple designs the products in Cupertino, and Foxconn builds them at scale across multiple massive facilities in mainland China.

Apple’s example is the one that proves offshoring can scale to the largest company on the planet. Apple is worth more than $3 trillion, and its production model is fundamentally an offshore one. The lesson isn’t that every company should outsource manufacturing to China; it’s that the “offshore equals lower quality” objection is mostly a story we tell ourselves to avoid an uncomfortable conversation about cost and capacity at home.

2. IBM in India

IBM runs one of the largest captive offshore operations on the planet. The Indian arm of the company employs more than 130,000 people across Bangalore, Hyderabad, Pune, Chennai, and other tech hubs. It handles consulting services, software development, research and development, and cloud monitoring for IBM’s global client base.

IBM India is the example most often cited for “offshoring done at scale.” The lesson is that IBM didn’t outsource the work to a vendor; they built their own subsidiary, hired their own employees, and kept full control of the operation. That’s the captive offshoring model, and it works when you have the scale to justify the overhead of running your own office on the other side of the world.

3. General Electric in Bangalore

GE’s John F. Welch Technology Centre in Bangalore is the company’s second-largest R&D operation in the world, behind only the original Niskayuna, New York campus. It runs research, engineering, and software development for GE’s aviation, healthcare, and energy divisions, and it talks to GE business units in every country the company operates in.

GE’s example proves the point that offshore destinations can absorb high-end engineering work, not just back-office tasks. The Bangalore facility files patents. It contributes to global product launches. Treating offshore as a “low-cost coding shop” is the limit your own thinking puts on it, not a limit of the talent pool.

4. Ford Motor Company’s India IT operations

Ford Motor Company runs a software development and IT services center in India that supports the company’s global e-commerce platforms, dealer systems, and customer support infrastructure. The center handles email, chat, and phone support for Ford’s worldwide markets, plus the technical platforms underneath the dealer network. Commerce platforms at that scale are real engineering, and the distance between them and a template storefront is exactly what e-commerce development actually involves.

The Ford example highlights a less-discussed offshoring benefit: 24-hour operations. When the Detroit office is closed, the India team is running. When India is closed, Detroit and the European offices cover. For a global automaker selling cars across every time zone, that always-on coverage isn’t a nice-to-have, it’s the entire point.

5. JPMorgan Chase in the Philippines

JPMorgan Chase runs offices in Metro Manila and a captive site in Cebu City, Philippines. The Philippine operation handles mortgage processing, IT support, and customer service for JPMorgan’s US-based retail and wholesale businesses, plus part of the bank’s global technology infrastructure.

JPMorgan’s example is the one that opens eyes inside financial services specifically. If a regulated bank with the strictest compliance overhead in the industry can run mortgage operations and customer service from Cebu City, the “you can’t offshore regulated work” objection is mostly a story about the model, not the geography. JPMorgan picked the Philippines for the same reasons most offshore providers do: English proficiency, time zone overlap with the US East Coast in the morning, and a workforce comfortable with Western business norms.

6. Amazon’s customer service center in Cebu

In 2018, Amazon opened its first Philippine customer service center in Cebu, joining the same offshore destination that JPMorgan and Full Scale both operate out of. The Cebu center provides 24/7 customer support for Amazon’s North American and UK customers across phone, chat, and email.

Amazon’s choice of Cebu specifically is worth pausing on. Cebu City is the second-largest IT and BPO hub in the Philippines after Manila, and it’s where a lot of the better engineering work in the country has consolidated over the last decade. Full Scale runs our own engineering office there for the same reasons Amazon does.

3 offshoring examples that failed (and why)

The success stories are easy to find. The failure stories are more useful, because they’re where the actual lessons live, and I’ve collected more offshore development horror stories worth learning from.

1. Accenture and the Hertz lawsuit

Accenture took on a contract to build a new website and mobile app platform for Hertz starting in 2016. The project ran past its original deadlines and budget, and in 2019, Hertz sued Accenture for $32 million, claiming Accenture had failed to deliver a working product, missed key milestones, and built software that didn’t support Hertz’s international operations even though those were in the original spec.

Accenture used offshore labor across India and other locations to staff parts of the project. The lawsuit didn’t fault offshore developers per se; it faulted Accenture’s project management, scope control, and quality assurance. The lesson here is the most important one in this whole post: when the model is project outsourcing, the geography of the developers is rarely the actual problem. The vendor’s accountability for delivery is. A project outsourcing engagement that ends in a lawsuit would have ended in a lawsuit no matter where the developers were sitting.

2. Navitaire and the Virgin Blue outage

In September 2010, Virgin Blue (the Australian carrier later renamed Virgin Australia) had its check-in and reservation systems go down for nearly 24 hours because of a hardware failure in the platform run by Navitaire, an Amadeus subsidiary that operates airline IT systems from offshore data centers and engineering teams. The outage stranded thousands of passengers and led to hundreds of flight cancellations across Australia.

The same platform had a second major failure within months. Virgin Blue eventually sued Navitaire and reached a multi-million-dollar settlement.

Navitaire’s example shows what happens when offshore infrastructure runs critical operations without enough redundancy in the model. The failure wasn’t that the engineering team was offshore; it was that the disaster recovery plan didn’t match the criticality of the system. Any infrastructure of that scale, on any continent, needs better failover than what Navitaire had in 2010.

3. IBM and Queensland Health’s payroll project

In 2007, the Queensland Health department in Australia contracted IBM to build a new payroll system. The original budget was $6 million. By the time the project was abandoned years later, it had cost over $1.2 billion, the software had paid thousands of nurses incorrect amounts (sometimes zero, sometimes wildly inflated), and the resulting royal commission found systemic failures in both IBM’s delivery and Queensland Health’s oversight.

IBM is also on the successes list above, which proves that the same company can run a great captive offshore operation in India and still botch a project outsourcing engagement somewhere else. The model and the customer matter as much as the vendor.

What the failures have in common

Three companies above, three different industries, three different geographies, three different decades. The common thread isn’t the country the developers were in. It’s that all three were project outsourcing engagements where the customer handed a spec to a vendor and trusted the vendor to deliver. None of them were staff augmentation, where the customer keeps full control of the team, the priorities, and the codebase.

Most of the data on why offshore projects fail traces back to this same root cause. Project outsourcing fails for structural reasons (misaligned incentives, scope drift, no continuity of knowledge) that have nothing to do with where the developers live. Staff augmentation, where the developers are part of your team and you’re directing the work, doesn’t suffer from those problems.

That distinction is the most important takeaway from any list of offshoring examples. Pick the right model and the country mostly doesn’t matter. Pick the wrong model and the country can’t save you.

Full Scale’s own offshoring examples

The success and failure cases above are all large enterprise engagements. The same patterns hold at startup and mid-market scale, just on a smaller stage.

AMC Theatres has been running offshore .NET engineers through Full Scale for years as part of their core engineering team. They use the staff augmentation model: every developer is dedicated to AMC, takes direction from AMC’s tech leads, and ships code into AMC’s repos. The team has been stable enough to be effectively indistinguishable from in-house, which is the whole point of the model.

The Stackify story is the other one I keep coming back to. I built a Philippines engineering team of 20+ developers at Stackify starting in 2018. When Stackify sold to Netreo in 2021 and then to BMC in 2024, every developer transferred to the new owner without renegotiation, both times. That’s the proof point: when you set up the engineering team correctly from the start, the team becomes an asset that survives the company, the acquisition, and the next acquisition after that.

Those examples are the operational version of what IBM, GE, and JPMorgan do at enterprise scale. Same model, smaller numbers, same result.

How to use these offshoring examples in your own decision

The examples above are useful for two specific decisions: whether to outsource software development at all, and how to evaluate the offshore providers you’re considering. For the full decision framework, see my guide to offshore outsourcing.

The pattern that comes out across all 9 examples (6 successes, 3 failures) is consistent. The companies that won at offshoring picked staff augmentation or captive models, kept direction and accountability in-house, and gave the offshore team enough continuity to actually build deep knowledge. The companies that lost picked project outsourcing and hoped that the contract language would protect them when the spec drifted or the quality slipped.

If you’re at the point of picking an offshore partner, that’s the question worth asking first. Not “where will the developers be?” but “what’s the model, and who owns delivery accountability when things change?”

Want to skip the research?

If the examples above are pointing you toward offshore as a real option, that’s what we do at Full Scale. We run a Philippines engineering operation of more than 350 developers, we’ve been on the Inc. 5000 list four years in a row, and the staff-augmentation model we use is the same one I built at Stackify because it’s the one I needed to exist.

Talk to us about hiring developers in the Philippines or read more about our offshore software development services. We can usually have qualified candidates in front of you inside a week.