Skip to main content
IBM Quantum Platform

Migrate from BackendV1 to BackendV2

The Qiskit BackendV1 class has been deprecated and will be removed from service. This migration guide describes the small adjustments you need to make if you use a provider that upgraded from BackendV1 to BackendV2.

Note

If you exclusively use qiskit_ibm_runtime and qiskit_aer, no action is needed. The qiskit_ibm_runtime package has always used BackendV2, and qiskit_aer has used BackendV2 since version 0.13.


High-level changes in BackendV2

The Qiskit Backend model was designed to provide the Qiskit SDK with an abstraction layer that enabled reasoning about quantum computers within the scope of the SDK. The first iteration of the model was introduced with the BackendV1 class. This class stored the backend information in a series of data containers, namely the BackendConfiguration and BackendProperties classes.

The BackendV2 class redefined user access for most backend properties to make them work with native Qiskit data structures and have flatter access patterns. The core of the BackendV2 model is the Target class, a representation of the QPU that contains the transpilation constraints that Qiskit can use to optimize circuits for execution.

The Qiskit SDK has been updated to work exclusively with BackendV2 inputs, and most providers have upgraded from BackendV1 to BackendV2. It is expected that existing providers will deprecate the old access where possible to provide a graceful migration, but eventually users will need to adjust their code.

The principle behind BackendV2 is that most of the information about a backend is contained in its Target object, and the backend's attributes often query its BackendV2.target attribute to return information. However, in many cases the attributes only provide a subset of information that the target can contain. For example, backend.coupling_map returns a CouplingMap constructed from the Target accessible in the BackendV2.target attribute. However, the target might contain instructions that operate on more than two qubits (which can't be represented in a CouplingMap) or it might have instructions that only operate on a subset of qubits (or two qubit links, for a two qubit instruction), which won't be detailed in the full coupling map returned by BackendV2.coupling_map. So depending on your use case, it might be necessary to look deeper than just the equivalent access with BackendV2.


Specific changes in BackendV2

Most attributes have a direct replacement, simplifying the migration efforts. The only point of mismatch between interfaces is in the CouplingMap.

Following is a table of example access patterns in BackendV1 and the new form with BackendV2.

Important

Scroll to the right to see important notes.

BackendV1BackendV2Notes
backend.configuration().n_qubitsbackend.num_qubits
backend.configuration().coupling_mapbackend.coupling_mapThe return from BackendV2 is a CouplingMap object. In BackendV1 it is an edge list. Also, this is just a view of the information contained in backend.target which may only be a subset of the information contained in the Target object.
backend.configuration().backend_namebackend.name
backend.configuration().backend_versionbackend.backend_versionThe BackendV2.version attribute represents the version of the abstract Backend interface that the object implements, while BackendV2.backend_version is metadata about the version of the backend itself.
backend.configuration().basis_gatesbackend.operation_namesThe BackendV2 returns a list of operation names contained in the backend.target attribute. The Target might contain more information than can be expressed by this list of names. For example, some operations only work on a subset of qubits, and some names implement the same gate with different parameters.
backend.configuration().dtbackend.dt
backend.configuration().dtmbackend.dtm
backend.configuration().max_experimentsbackend.max_circuits
backend.configuration().online_datebackend.online_date
InstructionDurations.from_backend(backend)backend.instruction_durations
backend.defaults().instruction_schedule_mapbackend.instruction_schedule_map
backend.properties().t1(0)backend.qubit_properties(0).t1
backend.properties().t2(0)backend.qubit_properties(0).t2
backend.properties().frequency(0)backend.qubit_properties(0).frequency
backend.properties().readout_error(0)backend.target["measure"][(0,)].errorIn BackendV2, the error rate for the Measure operation on a given qubit is used to model the readout error. However, a BackendV2 object can implement multiple measurement types and list them separately in a Target.
backend.properties().readout_length(0)backend.target["measure"][(0,)].durationIn BackendV2, the duration for the Measure operation on a given qubit is used to model the readout length. However, a BackendV2 object can implement multiple measurement types and list them separately in a Target.
Was this page helpful?
Report a bug or request content on GitHub.