diff --git a/docs/architecture-decisions/adr002-default-catalog-file-format.md b/docs/architecture-decisions/adr002-default-catalog-file-format.md
index 6cf649aedf..00c8b0947d 100644
--- a/docs/architecture-decisions/adr002-default-catalog-file-format.md
+++ b/docs/architecture-decisions/adr002-default-catalog-file-format.md
@@ -52,7 +52,7 @@ This is an example entity definition with some mocked data.
 
 ```yaml
 ---
-apiVersion: backstage.io/v1beta1
+apiVersion: backstage.io/v1alpha1
 kind: Component
 metadata:
   name: frobs-awesome
@@ -96,8 +96,8 @@ Backstage specific entities have an `apiVersion` that is prefixed with
 same type of structure. This may be relevant when co-hosting these
 specifications with e.g. kubernetes object manifests.
 
-Early versions of the catalog will be using beta versions, e.g.
-`backstage.io/v1beta1`, to signal that the format may still change. After that,
+Early versions of the catalog will be using alpha/beta versions, e.g.
+`backstage.io/v1alpha1`, to signal that the format may still change. After that,
 we will be using `backstage.io/v1` and up.
 
 ### `metadata`
@@ -213,10 +213,10 @@ Values can be of any length, but are limited to being strings.
 
 ## Component
 
-| Field        | Value                  |
-| ------------ | ---------------------- |
-| `apiVersion` | `backstage.io/v1beta1` |
-| `kind`       | `Component`            |
+| Field        | Value                   |
+| ------------ | ----------------------- |
+| `apiVersion` | `backstage.io/v1alpha1` |
+| `kind`       | `Component`             |
 
 The `spec` object for this kind is as follows:
 
diff --git a/docs/architecture-decisions/adr005-catalog-core-entities.md b/docs/architecture-decisions/adr005-catalog-core-entities.md
index 578eb72b91..d607dc62fb 100644
--- a/docs/architecture-decisions/adr005-catalog-core-entities.md
+++ b/docs/architecture-decisions/adr005-catalog-core-entities.md
@@ -37,7 +37,7 @@ Component entities are typically defined in YAML descriptor files next to the
 code of the component, and could look like this (actual schema will evolve):
 
 ```yaml
-apiVersion: backstage.io/v1beta1
+apiVersion: backstage.io/v1alpha1
 kind: Component
 metadata:
   name: my-component-name
@@ -63,7 +63,7 @@ wouldn't need their own descriptor files, but would be stored in the catalog
 somewhat like this (actual schema will evolve):
 
 ```yaml
-apiVersion: backstage.io/v1beta1
+apiVersion: backstage.io/v1alpha1
 kind: API
 metadata:
   name: my-component-api
@@ -97,7 +97,7 @@ files, but would be stored in the catalog somewhat like this (actual schema will
 evolve):
 
 ```yaml
-apiVersion: backstage.io/v1beta1
+apiVersion: backstage.io/v1alpha1
 kind: Resource
 metadata:
   name: my-component-db
diff --git a/docs/features/software-catalog/descriptor-format.md b/docs/features/software-catalog/descriptor-format.md
index 96707d12df..a9fc17ce75 100644
--- a/docs/features/software-catalog/descriptor-format.md
+++ b/docs/features/software-catalog/descriptor-format.md
@@ -2,11 +2,11 @@
 
 This section describes the default data shape and semantics of catalog entities.
 
-This both applies to objects given to and returned from the software catalog API,
-as well as to the descriptor files that the software catalog can ingest natively. In
-the API request/response cycle, a JSON representation is used, while the descriptor
-files are on YAML format to be more easily maintainable by humans. However, the
-structure and semantics is the same in both cases.
+This both applies to objects given to and returned from the software catalog
+API, as well as to the descriptor files that the software catalog can ingest
+natively. In the API request/response cycle, a JSON representation is used,
+while the descriptor files are on YAML format to be more easily maintainable by
+humans. However, the structure and semantics is the same in both cases.
 
 ## Contents
 
@@ -17,12 +17,12 @@ structure and semantics is the same in both cases.
 
 ## Overall Shape Of An Entity
 
-The following is an example of the shape of an entity as returned from the software
-catalog API.
+The following is an example of the shape of an entity as returned from the
+software catalog API.
 
 ```js
 {
-  "apiVersion": "backstage.io/v1beta1",
+  "apiVersion": "backstage.io/v1alpha1",
   "kind": "Component",
   "metadata": {
     "annotations": {
@@ -50,7 +50,7 @@ catalog API.
 The corresponding descriptor file that generated it may look as follows:
 
 ```yaml
-apiVersion: backstage.io/v1beta1
+apiVersion: backstage.io/v1alpha1
 kind: Component
 metadata:
   name: artist-web
@@ -68,8 +68,8 @@ spec:
 
 The root fields `apiVersion`, `kind`, `metadata`, and `spec` are part of the
 _envelope_, defining the overall structure of all kinds of entity. Likewise,
-some metadata fields like `name`, `labels`, and `annotations` are of
-special significance and have reserved purposes and distinct shapes.
+some metadata fields like `name`, `labels`, and `annotations` are of special
+significance and have reserved purposes and distinct shapes.
 
 See below for details about these fields.
 
@@ -81,71 +81,79 @@ The root envelope object has the following structure.
 
 The `kind` is the high level entity type being described.
 [ADR005](/docs/architecture-decisions/adr005-catalog-core-entities.md) describes
-a number of core kinds that plugins can know of and understand, but an organization
-using Backstage is free to also add entities of other kinds to the catalog.
+a number of core kinds that plugins can know of and understand, but an
+organization using Backstage is free to also add entities of other kinds to the
+catalog.
 
-The perhaps most central kind of entity, that the catalog focuses on in the initial
-phase, is `Component` ([see below](#kind-component)).
+The perhaps most central kind of entity, that the catalog focuses on in the
+initial phase, is `Component` ([see below](#kind-component)).
 
 The `apiVersion` is the version of specification format for that particular
-entity that the specification is made against. The version is used for being able to
-evolve the format, and the tuple of `apiVersion` and `kind` should be enough
-for a parser to know how to interpret the contents of the rest of the data.
+entity that the specification is made against. The version is used for being
+able to evolve the format, and the tuple of `apiVersion` and `kind` should be
+enough for a parser to know how to interpret the contents of the rest of the
+data.
 
 Backstage specific entities have an `apiVersion` that is prefixed with
-`backstage.io/`, to distinguish them from other types of object that share
-the same type of structure. This may be relevant when co-hosting these
+`backstage.io/`, to distinguish them from other types of object that share the
+same type of structure. This may be relevant when co-hosting these
 specifications with e.g. kubernetes object manifests, or when an organization
 adds their own specific kinds of entity to the catalog.
 
-Early versions of the catalog will be using beta versions, e.g. `backstage.io/v1beta1`,
-to signal that the format may still change. After that, we will be using
-`backstage.io/v1` and up.
+Early versions of the catalog will be using alpha/beta versions, e.g.
+`backstage.io/v1alpha1`, to signal that the format may still change. After that,
+we will be using `backstage.io/v1` and up.
 
 ### `metadata` [required]
 
-A structure that contains metadata about the entity, i.e. things that aren't directly
-part of the entity specification itself. See below for more details about this structure.
+A structure that contains metadata about the entity, i.e. things that aren't
+directly part of the entity specification itself. See below for more details
+about this structure.
 
 ### `spec` [varies]
 
 The actual specification data that describes the entity.
 
-The precise structure of the `spec` depends on the `apiVersion` and `kind` combination,
-and some kinds may not even have a `spec` at all. See further down in this document for
-the specification structure of specific kinds.
+The precise structure of the `spec` depends on the `apiVersion` and `kind`
+combination, and some kinds may not even have a `spec` at all. See further down
+in this document for the specification structure of specific kinds.
 
 ## Common to All Kinds: The Metadata
 
-The `metadata` root field has a number of reserved fields with specific meaning, described
-below.
+The `metadata` root field has a number of reserved fields with specific meaning,
+described below.
 
-In addition to these, you may add any number of other fields directly under `metadata`, but
-be aware that general plugins and tools may not be able to understand their semantics.
+In addition to these, you may add any number of other fields directly under
+`metadata`, but be aware that general plugins and tools may not be able to
+understand their semantics.
 
 ### `name` [required]
 
-The name of the entity. This name is both meant for human eyes to recognize the entity,
-and for machines and other components to reference the entity (e.g. in URLs or from
-other entity specification files).
+The name of the entity. This name is both meant for human eyes to recognize the
+entity, and for machines and other components to reference the entity (e.g. in
+URLs or from other entity specification files).
 
-Names must be unique per kind, within a given namespace (if specified), at any point in
-time. Names may be reused at a later time, after an entity is deleted from the registry.
+Names must be unique per kind, within a given namespace (if specified), at any
+point in time. Names may be reused at a later time, after an entity is deleted
+from the registry.
 
-Names are required to follow a certain format. Entities that do not follow those rules
-will not be accepted for registration in the catalog. The ruleset is configurable to fit
-your organization's needs, but the default behavior is as follows.
+Names are required to follow a certain format. Entities that do not follow those
+rules will not be accepted for registration in the catalog. The ruleset is
+configurable to fit your organization's needs, but the default behavior is as
+follows.
 
 - Strings of length at least 1, and at most 63
-- Must consist of sequences of `[a-z0-9A-Z]` possibly separated by one of `[-_.]`
+- Must consist of sequences of `[a-z0-9A-Z]` possibly separated by one of
+  `[-_.]`
 
 Example: `visits-tracking-service`, `CircleciBuildsDump_avro_gcs`
 
-In addition to this, names are passed through a normalization function and then compared
-to the same normalized form of other entity names and made sure to not collide. This rule
-of uniqueness exists to avoid situations where e.g. both `my-component` and `MyComponent`
-are registered side by side, which leads to confusion and risk. The normalization function
-is also configurable, but the default behavior is as follows.
+In addition to this, names are passed through a normalization function and then
+compared to the same normalized form of other entity names and made sure to not
+collide. This rule of uniqueness exists to avoid situations where e.g. both
+`my-component` and `MyComponent` are registered side by side, which leads to
+confusion and risk. The normalization function is also configurable, but the
+default behavior is as follows.
 
 - Strip out all characters outside of the set `[a-zA-Z0-9]`
 - Convert to lowercase
@@ -154,61 +162,65 @@ Example: `CircleciBuildsDs_avro_gcs` -> `circlecibuildsdsavrogcs`
 
 ### `namespace` [optional]
 
-The ID of a namespace that the entity belongs to. This is a string that follows the same
-format restrictions as `name` above.
+The ID of a namespace that the entity belongs to. This is a string that follows
+the same format restrictions as `name` above.
 
-This field is optional, and currently has no special semantics apart from bounding the
-name uniqueness constraint if specified. It is reserved for future use and may get broader
-semantic implication later. For now, it is recommended to not specify a namespace unless
-you have specific need to do so.
+This field is optional, and currently has no special semantics apart from
+bounding the name uniqueness constraint if specified. It is reserved for future
+use and may get broader semantic implication later. For now, it is recommended
+to not specify a namespace unless you have specific need to do so.
 
 Namespaces may also be part of the catalog, and are `v1` / `Namespace` entities,
 i.e. not Backstage specific but the same as in Kubernetes.
 
 ### `description` [optional]
 
-A human readable description of the entity, to be shown in Backstage. Should be kept short
-and informative, suitable to give an overview of the entity's purpose at a glance. More
-detailed explanations and documentation should be placed elsewhere.
+A human readable description of the entity, to be shown in Backstage. Should be
+kept short and informative, suitable to give an overview of the entity's purpose
+at a glance. More detailed explanations and documentation should be placed
+elsewhere.
 
 ### `labels` [optional]
 
-Labels are optional key/value pairs of that are attached to the entity, and their use is
-identical to [Kubernetes object labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/).
+Labels are optional key/value pairs of that are attached to the entity, and
+their use is identical to
+[Kubernetes object labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/).
 
-Their main purpose is for references to other entities, and for information that is
-in one way or another classifying for the current entity. They are often used as values
-in queries or filters.
+Their main purpose is for references to other entities, and for information that
+is in one way or another classifying for the current entity. They are often used
+as values in queries or filters.
 
 Both the key and the value are strings, subject to the following restrictions.
 
-Keys have an optional prefix followed by a slash, and then the name part which is required.
-The prefix, if present, must be a valid lowercase domain name, at most 253 characters in total.
-The name part must be sequences of `[a-zA-Z0-9]` separated by any of `[-_.]`, at most 63 characters
-in total.
+Keys have an optional prefix followed by a slash, and then the name part which
+is required. The prefix, if present, must be a valid lowercase domain name, at
+most 253 characters in total. The name part must be sequences of `[a-zA-Z0-9]`
+separated by any of `[-_.]`, at most 63 characters in total.
 
-The `backstage.io/` prefix is reserved for use by Backstage core components. Some keys such as
-`system` also have predefined semantics.
+The `backstage.io/` prefix is reserved for use by Backstage core components.
+Some keys such as `system` also have predefined semantics.
 
 Values are strings that follow the same restrictions as `name` above.
 
 ### `annotations` [optional]
 
 An object with arbitrary non-identifying metadata attached to the entity,
-identical in use to [Kubernetes object annotations](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/).
+identical in use to
+[Kubernetes object annotations](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/).
 
-Their purpose is mainly, but not limited, to reference into external systems. This could
-for example be a reference to the git ref the entity was ingested from, to monitoring
-and logging systems, to pagerduty schedules, etc. Users may add these to descriptor
-YAML files, but in addition to this automated systems may also add annotations, either
-during ingestion into the catalog, or at a later time.
+Their purpose is mainly, but not limited, to reference into external systems.
+This could for example be a reference to the git ref the entity was ingested
+from, to monitoring and logging systems, to pagerduty schedules, etc. Users may
+add these to descriptor YAML files, but in addition to this automated systems
+may also add annotations, either during ingestion into the catalog, or at a
+later time.
 
 Both the key and the value are strings, subject to the following restrictions.
 
-Keys have an optional prefix followed by a slash, and then the name part which is required.
-The prefix must be a valid lowercase domain name if specified, at most 253 characters in total.
-The name part must be sequences of `[a-zA-Z0-9]` separated by any of `[-_.]`, at most 63 characters
-in total.
+Keys have an optional prefix followed by a slash, and then the name part which
+is required. The prefix must be a valid lowercase domain name if specified, at
+most 253 characters in total. The name part must be sequences of `[a-zA-Z0-9]`
+separated by any of `[-_.]`, at most 63 characters in total.
 
 The `backstage.io/` prefix is reserved for use by Backstage core components.
 
@@ -218,19 +230,20 @@ Values can be of any length, but are limited to being strings.
 
 Describes the following entity kind:
 
-| Field        | Value                  |
-| ------------ | ---------------------- |
-| `apiVersion` | `backstage.io/v1beta1` |
-| `kind`       | `Component`            |
+| Field        | Value                   |
+| ------------ | ----------------------- |
+| `apiVersion` | `backstage.io/v1alpha1` |
+| `kind`       | `Component`             |
 
-A Component describes a software component. It is typically intimately linked to the source code
-that constitutes the component, and should be what a developer may regard a "unit of software",
-usually with a distinct deployable or linkable artifact.
+A Component describes a software component. It is typically intimately linked to
+the source code that constitutes the component, and should be what a developer
+may regard a "unit of software", usually with a distinct deployable or linkable
+artifact.
 
 Descriptor files for this kind may look as follows.
 
 ```yaml
-apiVersion: backstage.io/v1beta1
+apiVersion: backstage.io/v1alpha1
 kind: Component
 metadata:
   name: artist-web
@@ -241,22 +254,22 @@ spec:
   owner: artist-relations@example.com
 ```
 
-In addition to the [common envelope metadata](#common-to-all-kinds-the-metadata) shape, this kind has the
-following structure.
+In addition to the [common envelope metadata](#common-to-all-kinds-the-metadata)
+shape, this kind has the following structure.
 
 ### `apiVersion` and `kind` [required]
 
-Exactly equal to `backstage.io/v1beta1` and `Component`, respectively.
+Exactly equal to `backstage.io/v1alpha1` and `Component`, respectively.
 
 ### `spec.type` [required]
 
 The type of component as a string, e.g. `website`. This field is required.
 
-The software catalog accepts any type value, but an organisation should take great
-care to establish a proper taxonomy for these. Tools including Backstage itself may
-read this field and behave differently depending on its value. For example, a website
-type component may present tooling in the Backstage interface that is specific to just
-websites.
+The software catalog accepts any type value, but an organisation should take
+great care to establish a proper taxonomy for these. Tools including Backstage
+itself may read this field and behave differently depending on its value. For
+example, a website type component may present tooling in the Backstage interface
+that is specific to just websites.
 
 The current set of well-known and common values for this field is:
 
@@ -268,31 +281,33 @@ The current set of well-known and common values for this field is:
 
 The lifecyle state of the component, e.g. `production`. This field is required.
 
-The software catalog accepts any lifecycle value, but an organisation should take great
-care to establish a proper taxonomy for these.
+The software catalog accepts any lifecycle value, but an organisation should
+take great care to establish a proper taxonomy for these.
 
 The current set of well-known and common values for this field is:
 
-- `experimental` - an experiment or early, non-production component, signaling that users
-  may not prefer to consume it over other more established components, or that there are
-  low or no reliability guarantees
+- `experimental` - an experiment or early, non-production component, signaling
+  that users may not prefer to consume it over other more established
+  components, or that there are low or no reliability guarantees
 - `production` - an established, owned, maintained component
-- `deprecated` - a component that is at the end of its lifecycle, and may disappear at a
-  later point in time
+- `deprecated` - a component that is at the end of its lifecycle, and may
+  disappear at a later point in time
 
 ### `spec.owner` [required]
 
-The owner of the component, e.g. `artist-relations@example.com`. This field is required.
+The owner of the component, e.g. `artist-relations@example.com`. This field is
+required.
 
-In Backstage, the owner of a component is the singular entity (commonly a team) that
-bears ultimate responsibility for the component, and has the authority and capability
-to develop and maintain it. They will be the point of contact if something goes wrong,
-or if features are to be requested. The main purpose of this field is for display
-purposes in Backstage, so that people looking at catalog items can get an understanding
-of to whom this component belongs. It is not to be used by automated processes to for
-example assign authorization in runtime systems. There may be others that also develop
-or otherwise touch the component, but there will always be one ultimate owner.
+In Backstage, the owner of a component is the singular entity (commonly a team)
+that bears ultimate responsibility for the component, and has the authority and
+capability to develop and maintain it. They will be the point of contact if
+something goes wrong, or if features are to be requested. The main purpose of
+this field is for display purposes in Backstage, so that people looking at
+catalog items can get an understanding of to whom this component belongs. It is
+not to be used by automated processes to for example assign authorization in
+runtime systems. There may be others that also develop or otherwise touch the
+component, but there will always be one ultimate owner.
 
-Apart from being a string, the software catalog leaves the format of this field open to
-implementers to choose. Most commonly, it is set to the ID or email of a group of people
-in an organizational structure.
+Apart from being a string, the software catalog leaves the format of this field
+open to implementers to choose. Most commonly, it is set to the ID or email of a
+group of people in an organizational structure.
diff --git a/packages/catalog-model/src/entity/policies/DefaultNamespaceEntityPolicy.test.ts b/packages/catalog-model/src/entity/policies/DefaultNamespaceEntityPolicy.test.ts
index 68658e5296..68f1cec649 100644
--- a/packages/catalog-model/src/entity/policies/DefaultNamespaceEntityPolicy.test.ts
+++ b/packages/catalog-model/src/entity/policies/DefaultNamespaceEntityPolicy.test.ts
@@ -24,13 +24,13 @@ describe('DefaultNamespaceEntityPolicy', () => {
 
   beforeEach(() => {
     withoutNamespace = yaml.parse(`
-      apiVersion: backstage.io/v1beta1
+      apiVersion: backstage.io/v1alpha1
       kind: Component
       metadata:
         name: my-component-yay
     `);
     withNamespace = yaml.parse(`
-      apiVersion: backstage.io/v1beta1
+      apiVersion: backstage.io/v1alpha1
       kind: Component
       metadata:
         name: my-component-yay
diff --git a/packages/catalog-model/src/entity/policies/FieldFormatEntityPolicy.test.ts b/packages/catalog-model/src/entity/policies/FieldFormatEntityPolicy.test.ts
index 14b44108e5..80cf70fbab 100644
--- a/packages/catalog-model/src/entity/policies/FieldFormatEntityPolicy.test.ts
+++ b/packages/catalog-model/src/entity/policies/FieldFormatEntityPolicy.test.ts
@@ -23,7 +23,7 @@ describe('FieldFormatEntityPolicy', () => {
 
   beforeEach(() => {
     data = yaml.parse(`
-      apiVersion: backstage.io/v1beta1
+      apiVersion: backstage.io/v1alpha1
       kind: Component
       metadata:
         uid: e01199ab-08cc-44c2-8e19-5c29ded82521
diff --git a/packages/catalog-model/src/entity/policies/NoForeignRootFieldsEntityPolicy.test.ts b/packages/catalog-model/src/entity/policies/NoForeignRootFieldsEntityPolicy.test.ts
index 50496682e8..03b0ed2eb5 100644
--- a/packages/catalog-model/src/entity/policies/NoForeignRootFieldsEntityPolicy.test.ts
+++ b/packages/catalog-model/src/entity/policies/NoForeignRootFieldsEntityPolicy.test.ts
@@ -23,7 +23,7 @@ describe('NoForeignRootFieldsEntityPolicy', () => {
 
   beforeEach(() => {
     data = yaml.parse(`
-      apiVersion: backstage.io/v1beta1
+      apiVersion: backstage.io/v1alpha1
       kind: Component
       metadata:
         uid: e01199ab-08cc-44c2-8e19-5c29ded82521
diff --git a/packages/catalog-model/src/entity/policies/ReservedFieldsEntityPolicy.test.ts b/packages/catalog-model/src/entity/policies/ReservedFieldsEntityPolicy.test.ts
index 5bc39f4e93..04acd58686 100644
--- a/packages/catalog-model/src/entity/policies/ReservedFieldsEntityPolicy.test.ts
+++ b/packages/catalog-model/src/entity/policies/ReservedFieldsEntityPolicy.test.ts
@@ -23,7 +23,7 @@ describe('ReservedFieldsEntityPolicy', () => {
 
   beforeEach(() => {
     data = yaml.parse(`
-      apiVersion: backstage.io/v1beta1
+      apiVersion: backstage.io/v1alpha1
       kind: Component
       metadata:
         uid: e01199ab-08cc-44c2-8e19-5c29ded82521
diff --git a/packages/catalog-model/src/entity/policies/SchemaValidEntityPolicy.test.ts b/packages/catalog-model/src/entity/policies/SchemaValidEntityPolicy.test.ts
index 9a3c02d85a..2113772af4 100644
--- a/packages/catalog-model/src/entity/policies/SchemaValidEntityPolicy.test.ts
+++ b/packages/catalog-model/src/entity/policies/SchemaValidEntityPolicy.test.ts
@@ -24,7 +24,7 @@ describe('SchemaValidEntityPolicy', () => {
 
   beforeEach(() => {
     data = yaml.parse(`
-      apiVersion: backstage.io/v1beta1
+      apiVersion: backstage.io/v1alpha1
       kind: Component
       metadata:
         uid: e01199ab-08cc-44c2-8e19-5c29ded82521
diff --git a/packages/catalog-model/src/kinds/ComponentEntityV1alpha1.test.ts b/packages/catalog-model/src/kinds/ComponentEntityV1alpha1.test.ts
index f1a4b3c2c0..a60bb2606b 100644
--- a/packages/catalog-model/src/kinds/ComponentEntityV1alpha1.test.ts
+++ b/packages/catalog-model/src/kinds/ComponentEntityV1alpha1.test.ts
@@ -44,7 +44,7 @@ describe('ComponentV1alpha1Policy', () => {
     await expect(policy.enforce(entity)).resolves.toBe(entity);
   });
 
-  it('happy path: silently accepts v1beta1 as well', async () => {
+  it('silently accepts v1beta1 as well', async () => {
     (entity as any).apiVersion = 'backstage.io/v1beta1';
     await expect(policy.enforce(entity)).resolves.toBe(entity);
   });
diff --git a/packages/catalog-model/src/kinds/LocationEntityV1alpha1.test.ts b/packages/catalog-model/src/kinds/LocationEntityV1alpha1.test.ts
index e3c8170af2..62837ed500 100644
--- a/packages/catalog-model/src/kinds/LocationEntityV1alpha1.test.ts
+++ b/packages/catalog-model/src/kinds/LocationEntityV1alpha1.test.ts
@@ -42,7 +42,7 @@ describe('LocationV1alpha1Policy', () => {
     await expect(policy.enforce(entity)).resolves.toBe(entity);
   });
 
-  it('happy path: silently accepts v1beta1 as well', async () => {
+  it('silently accepts v1beta1 as well', async () => {
     (entity as any).apiVersion = 'backstage.io/v1beta1';
     await expect(policy.enforce(entity)).resolves.toBe(entity);
   });
diff --git a/plugins/catalog-backend/src/ingestion/HigherOrderOperations.test.ts b/plugins/catalog-backend/src/ingestion/HigherOrderOperations.test.ts
index b4dd151e72..de68a16e9c 100644
--- a/plugins/catalog-backend/src/ingestion/HigherOrderOperations.test.ts
+++ b/plugins/catalog-backend/src/ingestion/HigherOrderOperations.test.ts
@@ -173,7 +173,7 @@ describe('HigherOrderOperations', () => {
         target: 'thing',
       };
       const desc: Entity = {
-        apiVersion: 'backstage.io/v1beta1',
+        apiVersion: 'backstage.io/v1alpha1',
         kind: 'Component',
         metadata: { name: 'c1' },
         spec: { type: 'service' },
@@ -228,7 +228,7 @@ describe('HigherOrderOperations', () => {
         target: 'thing',
       };
       const desc: Entity = {
-        apiVersion: 'backstage.io/v1beta1',
+        apiVersion: 'backstage.io/v1alpha1',
         kind: 'Component',
         metadata: { name: 'c1' },
         spec: { type: 'service' },
diff --git a/plugins/catalog/src/components/CatalogPage/CatalogPage.test.tsx b/plugins/catalog/src/components/CatalogPage/CatalogPage.test.tsx
index d30361d0e7..7601031699 100644
--- a/plugins/catalog/src/components/CatalogPage/CatalogPage.test.tsx
+++ b/plugins/catalog/src/components/CatalogPage/CatalogPage.test.tsx
@@ -38,7 +38,7 @@ describe('CatalogPage', () => {
           metadata: {
             name: 'Entity1',
           },
-          apiVersion: 'backstage.io/v1beta1',
+          apiVersion: 'backstage.io/v1alpha1',
           kind: 'Component',
         },
       ] as Entity[]),
diff --git a/plugins/catalog/src/components/CatalogTable/CatalogTable.test.tsx b/plugins/catalog/src/components/CatalogTable/CatalogTable.test.tsx
index c04e4c95a8..b50da60a50 100644
--- a/plugins/catalog/src/components/CatalogTable/CatalogTable.test.tsx
+++ b/plugins/catalog/src/components/CatalogTable/CatalogTable.test.tsx
@@ -22,17 +22,17 @@ import { CatalogTable } from './CatalogTable';
 
 const entites: Entity[] = [
   {
-    apiVersion: 'backstage.io/v1beta1',
+    apiVersion: 'backstage.io/v1alpha1',
     kind: 'Component',
     metadata: { name: 'component1' },
   },
   {
-    apiVersion: 'backstage.io/v1beta1',
+    apiVersion: 'backstage.io/v1alpha1',
     kind: 'Component',
     metadata: { name: 'component2' },
   },
   {
-    apiVersion: 'backstage.io/v1beta1',
+    apiVersion: 'backstage.io/v1alpha1',
     kind: 'Component',
     metadata: { name: 'component3' },
   },
diff --git a/plugins/catalog/src/components/EntityMetadataCard/EntityMetadataCard.test.tsx b/plugins/catalog/src/components/EntityMetadataCard/EntityMetadataCard.test.tsx
index e0027431ff..4bb64f221d 100644
--- a/plugins/catalog/src/components/EntityMetadataCard/EntityMetadataCard.test.tsx
+++ b/plugins/catalog/src/components/EntityMetadataCard/EntityMetadataCard.test.tsx
@@ -22,7 +22,7 @@ import { EntityMetadataCard } from './EntityMetadataCard';
 describe('EntityMetadataCard component', () => {
   it('should display entity name if provided', async () => {
     const testEntity: Entity = {
-      apiVersion: 'backstage.io/v1beta1',
+      apiVersion: 'backstage.io/v1alpha1',
       kind: 'Component',
       metadata: { name: 'test' },
     };