That is a great question, but not an easy one to answer.  The first question is are they the same software vendor.  If they are the same vendor, I would recommend that you develop an architecture that will help you support it more easily.  For example, divide engine based upon location or by functionality.  Location could be by hospital or clinic while functionality could be ADT/SCH versus ORU.  This also gives you an opportunity to build redundancy in case one system goes down.

If they are not the same software vendor, I strongly encourage to pick one vendor and convert.  There is tangible and intangible savings with going with one vendor.  The tangible savings will be the annual support fees, cross over training for personnel.  The intangible savings are on going support of two systems.  Conversion will have a one time expense

Great question!  First, let me state that the interface engineer that you are working with should test the logic of their code.  It should be their responsibility to ensure that the code is working as designed.  Second, as an application analyst there are two things that you should test.  The first is data validation within the receiving application.  For example, ADT interfaces you will want to make sure that the demographic information is being placed in the correct fields within the receiving application i.e. first name, last name, DOB, gender, and etc.  The second is what I call business logic.  Test to make sure that you get the desired patient population.  If you only want inpatients, test to make sure that outpatients do not come through.  If data is being mapped, make sure that the new values are coming through.  Next, verify that HL7 transaction are working accordingly in the receiving application.  For example if a patient is discharged, verify that the application shows they are discharge.
The best testing document is your interface specifications.  However, don't hesitation to test normal daily activities either.

More interface engines allow you to write code and save it.  This allows for you to do an external code within the interface engine.  For example, Filter by Patient Location is a procedure that you would use multiple times across many interfaces.  Write the procedure (or code) to pass in multiple locations and then pass back a pass/fail flag to the interface.  The pass/fail flag would either suppress or continue to process the record.
I would also recommend that you have a naming convention in place so it is easily recognized by multiple people.

There was a time in healthcare information technology that many software vendors would state, "Interfaces do not take any resources, so you can just add them."  I wish I had a dollar every time I heard that!  YES, you need to be monitoring your interface engine.  Many things can go wrong with interfaces.  There are hardware performance concerns that should be monitored.  In regards to the interfaces, data can stop flowing so queues need to be monitored.  Also, the end point applications can change without notice which can cause the engine to process data with results that are not desired.
I recommend to all of our clients to have at least one person who is trained and responsible for interfaces and interface engines.  It does not have to be an employee, but can be outsourced if budget is a concerned.  I also recommend that when an employee is utilized to have a back up person trained as well for vacations.

I would strongly recommend that you have a naming convention for your interfaces.  The two methods that work well are 1) name them by functionality i.e. ADT, ORM, ORU, etc.  It would look something like this ADT_EPIC_OUT_TO_PACS, or 2) by systems i.e. PACS, EMR, etc.  It would look something like this PACS_ ADT_EPIC_OUT or PACS_ORU_EPIC_IN. 

I can already hear the next question.  How do we get everyone to comply.  For employees, I would tie compliance to the naming convention to their annual review.  For contractors, I would add it to their contract.  Any consulting firm will welcome written standards.

The answer is YES!!  You should at least backup the interface engine once a week.  The best case scenario is a daily backup.  I have been called into companies to restore their interface engine after a fatal hardware crash, and they had not down any backups.  At this point, your only options is to begin rebuilding every interface from scratch.