TL,DR
EEVEE and Cycles are two completely separate render engines with very different approaches to produce an image.
You can't possibly expect to even remotely match a real time OpenGL based rasterizer with an unbiased path tracer image.
The long explanation
While they are very compatible to a certain degree, share most material and shader definitions; and the lamps and workflow are mostly interchangeable, they are very different under the hood, and quite opposite in very fundamental ways.
Both are aimed towards producing rendered images from a 3D model with varying degrees of realism, and both use a physically based approach to the definition of materials, but that is where the similarities end.
Cycles is a raytracer, a physically based unbiased path tracer, whose aim is to approach as closely as possible the real word physical phenomenon of light dispersion and interreflections through tracing of photon rays.
On the other hand EEVEE is rasterizer, a realtime OpenGL based render engine, compatible with PBR material creation. It has support for baked indirect lighting, screen space reflections, screen space ambient occlusion, and other modern commodities provided by current generation graphics hardware. While it is quite advanced and has extensive features to increase photo-realism it is easy to forget that at the end of the day it is still at its base a rasterizer (the most basic form of rendering computer graphics), with main purpose being speed and responsiveness over realism.
With this in mind it is virtually impossible to make a render made in EEVEE match one made in Cycles. Renders made with different engines would be very hard to match even for slightly different implementations of the same algorithm, let alone for two so fundamentally different rendering approaches.
You can't possibly expect a real time OpenGL based rasterizer to even remotely match a unbiased path tracer.
EEVEE

Cycles

This is easy to forget because both are deeply integrated into Blender, with a lot of common settings, having a similar workflow, sharing most material definitions and texture settings while using the same node tree based shader definitions. These similarities are very superficial, mostly at UI level however, under the hood very different calculations are happening and a whole lot of work has been put to make them work so well in tandem, and make their outputs match so closely.
Work is constantly being done to make the transition between the two as smooth as possible. Results are tweaked so that light intensity and material properties match as close as possible. Don't expect miracles however, there will always be differences between the two.
If EEVEE was ever able to produce the same results as Cycles at a fraction of the time we wouldn't really need raytracing at all, and Cycles would quickly become obsolete.
Here a few current limitations or real time rendering. EEVEE can´t really handle environment shader occlusion, HDRI world maps can't generate shadows and reflections are always visible regardless of occlusion, without baking. Most reflection types require baking for correct results, and don't handle interreflections too well. Transparent objects often can't be seen through other transparent objects and consecutive refraction effects don't carry over.
Solutions
Luckily, as user L0Lock mentions EEVEE and Cycles shader trees support multiple material outputs, and each can specify different target render engines within the same material, meaning you can tweak shaders to compensate for each render engine without having to make separate materials or fully rewrite your node trees.
Just add two Material Output Nodes to your shader tree, pick the render engine from the dropdown menu, and adjust your shader tree accordingly for each, diverging only where adjustments are required.

For lights, nodes are not yet supported in EEVEE, so if your lamp uses a node tree then EEVEE currently ignores it, virtually allowing you to tweak Cycles result from the node tree, while EEVEE will always display the direct result of the lamp at Object Data level properties, meaning you can independently tweak viewport results from the Properties Window parameters while Cycles uses the nodes one.
Otherwise if the results don't match well enough I'd advise creating two separate scenes, link all objects and data, then make unique users on a case-by-case basis for each single lamp or material that needs individual tweaking.