Two different things.
SCORM is composed of a student attempt data model called a CMI Object, which is JavaScript to JavaScript communication between the content and LMS Runtime API. Data is stored from the client to the LMS server typically on Commit or Terminate.
Content is packaged like small portable websites via a Content Aggregation Model or zip. This includes a xml (imsmanifest.xml) and assets capable of presenting the page(s). A Content API is typically in charge of connecting to the LMS Runtime, and initiating the communication which must adhere to the SCORM Specification.
Students log into the LMS, and the LMS prepares the student attempt before it loads the shareable content object. More of an assigned, Table of contents style approach.
xAPI or TinCan is a more modern twist enabling more than just HTML based technologies to establish a 'I did this' style statement which if you look up Activity Streams or dig deeper into what makes that all tick. For HTML it would be more AJAX posts against a endpoint (aka a OAuth style Restful web service). This means your app or webpage etc .. has to allow the student to authenticate and report to a specific server. There are a handful of LRS systems out there.
All things aside this is a question of adoption, and where your team wants to take the content being built or already built. SCORM is typically the go-to for sending it to other 3rd Party LMS systems. TinCan is in the adoption phase now so you may find more information googling around on prices and availablity.
Rustici has made a non-commercial SCORM Driver which supports AICC,SCORM 1.2, SCORM 2004 and xAPI. So depending on how deep the projects pockets are you can possibly come up with some level of failover between deployment goals.
Good Luck.