There're (at least) three options: interoperability, converting between standards, and free-for-all integration.
As discussed in Interoperability vs. Integration, interoperable systems work together because they implement a common standard, so they use agreed upon interfaces. Integration fills in the gap when there are no agreed upon interfaces.
Richard comments with a good NTSC/PAL TV/VCR analogy. If the TV and VCR are designed for two different standards, you need an adapter that converts between the standards.
Because of the two different standards, one can design a converter between them which itself is fairly standard and reusable. I'd say this is an example of a converter case, a case that's midway between interoperability and integration. Because the converter is going between agreed upon standards, I'd say it's closer to interoperability than integration.
In many (most?) integration projects, none of the systems implements any standards. So the converter is a bunch of stuff that need to be very customized and often isn't reusable.
Another random example of the difference: Back in the good old days of MS-DOS, each application needed its own driver for every printer. Each app would come with diskettes containing dozens of different printer drivers, and the same printer would need different drivers for different apps. Windows helped unify this by developing a standard (within Windows) printer API. Each app would use this API to print, and each printer vendor would implement a driver for this API. Windows made apps and printers interoperable.
So the moral is, perhaps: If you can't develop to an agreed upon standard for interoperability, at least develop to some standard. Odds are that this will make integration simpler, perhaps as simple as sticking in some reusable converters.