I recommend reaching out from the Episerver site and fetch the data in some format you can export or expose. Then update or create content inside the Epi site.

For complex import scenarios it's a lot easier to have access to the full Episerver .NET API than being in the middle and "shooting" data into some service layer/HTTP endpoint etc.

@Johan - I assume you meant reaching out from Sitecore

Content migrations are never one solution fits all. But here's how I approach it and some questions I ask the client:

1. Create a content inventory document of all the pages, contents, templates, rendering and the fields within Sitecore. This will also help your testers to ensure everything was moved over from old to the new site.
2. Create a mapping document that maps each of these items to the respective page types, block types etc. within epi.
3. Do any pages, contents, assets need special treatment? What about users, roles, personalization, custom data, modules etc.? How do they move over?
4. What about business logic within code?
5. Do ask them if you are responsible for setting up 301 redirects from the old to the new site (since the URLs may change).
6. There will be some content that will have to be moved manually, no matter what.
7. Once you have that, you can run some scripts to package up sitecore data to parsable format (XML, JSON etc.). That way it's predictable and a lot can be automated.
8. Lastly, what about content freeze. Migrations can run from a few days to months depending on the size of the database. Most migrations will need you to run the scripts multiple times to avoid loss of data.

@Aniket, while I agree with your plan above (important points!), I believe Johan actually did mean reaching out from Episerver - i.e., running the actual content import as a run-once Episerver scheduled job or admin tool. Of course, the content from Sitecore would have to be exposed in a consumable format first, but running the import job from within Episerver gives you access to all Episerver's APIs for handling content. 

While Episerver also has a tool for importing content packages (which are essentially zipped .xml's and assets), using the content API directly will be much faster than converting Sitecore content to Episerver's import format.

EMVP Jon D. Jones has written some tips on creating such a migration job here: http://jondjones.com/learn-episerver-cms/episerver-developers-guide/episerver-scheduled-tasks/episerver-content-migration-with-jsonnet

Arild understood what I meant

To reduce manual steps when migrating and if you know and have access to the Sitecore source code you could and expose the source data in a Web API on that end.

To handle internal links for other content and media you most likely need a migration process that can run multiple times and we have found it smart to be able to select different starting points and destinations as well.

I don't know much about Sitecore but a 1-to-1 complete migration is rarely a possibility and not desirable either, even when migrating between two different Episerver sites I would say. Good to get rid of some debt and modernize the architecture while you're in such a big process.