only. It is further understood that one possessing ordinary skill in the art, in light of known systems and methods, would appreciate the use of the invention for its intended purposes and benefits in any number of alternative embodiments, depending upon specific design and other needs. [0014] An embodiment of the present invention is directed to extending an existing Open Service Broker API™ specification to manage an entire service lifecycle and service migration across multiple cloud platforms. [0015] According to an exemplary embodiment, the framework may include three representative components including Service Provider (SP), Platform Component (PC) and Service Framework Registry (SFR). [0016] The Service Provider (SP) may build, own and/or run services. Services may be broadly classified into categories such as Data, Messaging, Logging, Monitoring, API gateways, etc. The service provider may implement a standard API to manage service discovery, provisioning and consumption. The SP API may be protected using a standard, such as OpenID Connect (OIDC) standard, to ensure only trusted components are allowed to manage a service lifecycle. For example, the Service Provider broker may register itself against a Service Framework Registry (SFR). The SP API may expose a health endpoint, which may be used by the platform to infer provisioning health, quota availability and/or handle error scenarios. [0017] The Platform Component (PC) may represent an entity that builds, deploys and/or operates different cloud platform instances in multiple datacenter and zones. For example, the PC may run an implementation of the SP API, which may act as a bridge between a Cloud platform ( e.g ., Kubernetes, Pivotal Cloud Foundry, etc.) and the SP API. The PC may act as a generic service broker acting on behalf of some or all the SP APIs within the boundary of the