To most employees, it really is. And the reason is simple: they think their job will be replaced by someone sitting in India, Vietnam, China, or wherever and they will be out of work.
Sure, sometimes this really is the case. In some companies, to save costs, they will close down some or all of the engineering department and send that work offshore. In those cases, the engineers onshore are out of work and must scramble to find other employment. But in truth, this is a very rare situation. Entire development teams are seldom let go, for the simple reason that offshoring isn't a simple as people think and it won't result in the same amount of work being done unless properly managed, and unless the executives have experience off shoring, that is not likely the case and a huge mistake has been made.
More typically, offshoring is done to complement an existing team, adding resources at a lower cost than possible onshore, or to gain other advantages such as two shift development or a nightly QA cycle. In these cases, which are always the ones in which I've managed offshore teams, there's no threat at all to the onshore team jobs, and any fears they have about that need to be allayed as quickly as possible. In these cases, explaining the reasons for offshoring to the team in a meeting is crucial. Make the case, clearly and objectively, explain the role of the offshore team and why it is being put in place, and explain the impact it will have on the existing onshore team. explaining the logic helps the team understand the reasoning, and if they trust you, they will accept the reasons and perhaps even welcome the offshore team effort.
If you, as a leader, are new to the team, there's bound to be scepticism. This has happened several times in my career where I've explained to a new team why I am putting a team offshore in Vietnam (almost always starting with a QA shift, but sometimes with a development team). The "don't worry, your job is safe" line gets greeted with skepticism, as it should, as I am unproven to the team and I have yet to earn their trust. Even so, I go to great lengths to explain the reasons for the offshore team and what they will do, how I see them complementing and working with the onshore team, and what I need from them to make this a success. Even if they don't entirely buy in, in most cases they are willing to give it a go and see what happens.
If you have their trust already, things go much easier. An onshore QA team is usually overloaded and can see the logic in hiring several new bodies offshore to help with the load, and to pass off the more mundane tasks. They can see the logic of having a night-time testing cycle to complement their day-time efforts, and they are aware that for the cost of hiring five new QA bodies onshore they could have triple or quadruple that number offshore. The whole key for me to justify the offshore team is to promise no onshore jobs will be lost. If anything, the onshore jobs get more interesting. And then I have to stick to that promise. I've had the pleasure of working with some really talented and clever QA directors (Romi, Martha, Gurs....I mean you!) all of whom saw the advantages of a night-shift QA at reduced cost, and not just embraced the idea but worked hard to ensure its success. Once the offshore team has ramped up and is productive, everyone in the group sees the advantages, and the offshore team can become part of the onshore effort with little thought about "us versus them".
Development offshore teams are a bit harder to justify for onshore developers, but there are ways to position it that are both advantageous and, hopefully, true. When I start setting up offshore teams, I have them do one of two kinds of work: either the boring development stuff my onshore team doesn't like doing, or working on separate projects. Doing the boring stuff is the easiest way to gain the offshore team some acceptance, if not respect, from the onshore developers. My onshore team would much rather do the "clever" stuff and leave the "boring" stuff to junior developers onshore or an offshore team. If this is truly the case, then it's easy to position and get accepted by the onshore team. Separate projects are a good way to get the offshore team up and running, tested as to quality and work habits, and ensure they are more accepted by the onshore team as well. By stand-alone projects, I mean tasks that can be done in isolation without onshore participation except management and review. I keep initial projects small, to a few month's duration or less, so the results can be examined and evaluated by onshore resources. (That is, in fact, something I always do to help the offshore team get accepted: I have some of my onshore developers review what the offshore team did and come up with appraisals. If the code is not good, then it's useful to provide feedback to the offshore team. If the code is in fact good, then it helps the onshore team have respect for the offshore team.)
In the end, as long as the offshore team is not being ramped up to replace onshore resources, but rather to complement them, it just takes time for the offshore team to get accepted. Going back to my key leadership technique of communications, explaining the offshore effort to the onshore team clearly is the key. Explain what they team will do, how they will be managed, how the results will be measured, and what you need from the onshore team, and offshoring slowly doesn't mean something bad any more.