Service-Oriented Architecture (SOA) has become a widespread architecture and integration means in companies due to increased use and maturing of standards, technologies, tools and platforms. In order to achieve balance between long-term goals and short-term business needs, companies have to establish an appropriate organizational and operational mode from the beginning of service-oriented architecture initiatives. The backbone of an SOA roadmap development process is the maturity model. However, maturity models cannot provide a concrete roadmap because they are focused on a concise description of the most important information about the architecture and not on the complex interaction of multiple factors. To start the transformation to a service oriented architecture successfully, precisely these factors, namely practices, need to be identified. Therefore, a reference maturity model is defined to which various maturity models will be compared. This enables us to analyze the capabilities that belong to the first level of maturity since our goal is to identify and overcome those practices in order to achieve an opportunity for a higher level of maturity. In the first step of the research, the maturity models are compared in order to determine which levels are compatible with the first level. The literature review in this paper is focused primarily on service-oriented architecture maturity models as the most commonly used and available maturity models. In addition, their capabilities are described adequately and in detail. A comparative analysis approach is used to transfer the analyzed service-oriented architecture maturity models to the proposed reference maturity model. The second step of the research includes the analysis of capabilities from the maturity levels of the analyzed service-oriented architecture maturity models that correspond to the first level. In formulating common practices in SOA implementation, it is used relational content analysis method to select the core practices. A domain-independent analysis of capabilities is conducted since different maturity models have differently defined capability domains. The most difficult part was to identify practices concealed behind the description capability and to detect at which knowledge or application level they can be expected. Moreover, the same practice was described in several capability domains and it was often applied at a higher maturity level in the broad enterprise segment. The key practices derived from the analysis of maturity capabilities at the stability level of maturity are: service layers, business object services, integration center, error-handling framework, security, versioning and basic governance. One of the key practices, error-handling framework, was identified as most important in SOA-based systems. Composite applications must be reliable and available, in the same manner as traditional applications. Due to the multi-layered architecture of the service oriented architecture, however, this may appear more difficult to achieve. It is necessary to use an effective error-handling method in order to increase system fault tolerance. The aim of the second part of this research is to present an error-handling framework by means of the platform properties that are used for building the service-oriented architecture platform. Taking into account the analysis of the factors that influence the error-handling strategy, we can summarize that we need a framework that will be able to handle runtime errors deriving from the partner service call (whether the cause be on the client or the server part), and for synchronous and asynchronous processes using available recovery actions and including the necessary roles in the organization. One of the main requirements is to avoid writing a code for error handling inside the BPEL process, preferably any such code. Furthermore, such framework should minimize the number of terminated processes and recovery time. The framework is based on the capacity of the SOA platform that enables the BPEL engine to intercept an error before it occurs in the process and recovery actions. The proposed framework is built using service-oriented architecture platform as a proof-of-concept. The implementation relies on middleware and BPEL engine capabilities. The current generation of middleware enables handling of some errors outside the process definition, which provides us the possibility to write process and focus on the business problem without the burden of error-handling code. An error framework such as this has a limitation that depends on middleware APIs that are not standardized. At least, users will be acquainted with properties and features of middleware when selecting SOA products. We expect in future that more platform features will be as “out of the box” as those we have created in this framework. Finally, we need improved transaction control to completely control a business process. Future study could provide a case study analysis in order to confirm or disprove these practices.