Migrate from Atlassian Statuspage to OneUptime: what the move involves
If your Statuspage renewal, a data residency requirement or lock-in concerns have pushed you toward OneUptime, the core of the move is straightforward: export components, incidents and subscribers through the Statuspage API, then rebuild the pages in OneUptime Community Edition and cut over. Plan the work as a data export, a page rebuild and a subscriber transition, in that order. Each step can fail independently, so treat them as separate deliverables with their own checks. The work usually falls to an internal platform or SRE team that already runs production services, with an implementation partner sometimes brought in for the hosting, single sign-on and cutover runbook. Statuspage's API is rate limited, so the export needs a script that paces its requests and keeps a record of what it has pulled. Before you start, confirm with Atlassian which export fields your plan returns, and confirm with OneUptime which Community Edition features your deployment method supports. Agree a rollback path, because the old page is your fallback until the new one has carried a real incident.
Effort and risk are concentrated in three places: component structure, subscriber consent and history fidelity. Statuspage components rarely map one to one onto OneUptime monitors and status page resources, so decide the target structure before importing anything. Subscriber lists cannot be moved as if they were consent; confirm what each subscriber agreed to and whether your notification provider permits re-subscription. Incident history imports well as text but may lose formatting and timestamps if the mapping is careless. OneUptime covers more than the status page. Its Community Edition also includes incident management from declaring through post-mortems, and on-call schedules with escalation by SMS, phone call, push, email and Slack. That breadth can justify moving alerting and on-call in the same project, but it also widens scope, so decide early whether you are replacing only the public status page or the wider incident workflow. Ask your implementation partner for a written scope that names each of these areas.
Which Statuspage capabilities map to OneUptime and which need rework
This table maps each Statuspage capability to its closest OneUptime equivalent and marks it as clean, needs rework or gap. Read the status column first, then the notes, to plan which pages, subscribers and access rules can move as-is and which need rebuilding. Confirm custom domain and subscriber import details against the OneUptime repository before you commit to a cutover date.
| Statuspage capability | OneUptime equivalent and status | What to check before cutover |
|---|---|---|
| Public status pages | Clean: branded public pages are included in Community Edition | Recreate page branding, logo and layout; confirm the page structure matches your current public page |
| Private status pages | Clean: branded private pages are included in Community Edition, with SAML and OIDC single sign-on | Map each audience group to an SSO group; test access for employees before retiring the Statuspage private page |
| Components and component groups | Needs rework: components are rebuilt as OneUptime monitors or manual components | Decide per component whether it is automated from a monitor or updated by hand during incidents |
| Incident history | Needs rework: past incidents are re-entered or imported, and the import path must be confirmed | Export incident history through the Statuspage API and confirm the import method in the OneUptime repository |
| Scheduled maintenance | Clean: scheduled maintenance is included in Community Edition | Re-create upcoming maintenance windows so the status page shows them before the switch |
| Subscriber notifications | Needs rework: subscribers must be re-imported or re-consented, and delivery channels reconfigured | Do not copy subscriber lists without a record of consent; confirm subscriber import details in the repository |
| Custom domains | Needs rework: DNS for each status page must point to the new host and the certificate must be issued | Confirm the custom domain setup steps in the repository; plan a parallel run before changing DNS |
| Team access and roles | Gap for granular provisioning: SCIM provisioning is in the Enterprise Edition | Community Edition covers SSO sign-in; plan manual user management or confirm Enterprise Edition needs with OneUptime |
| Audit logs and data residency | Gap in Community Edition: both are in the Enterprise Edition | If an assessor expects audit logs or residency controls, request the Enterprise Edition scope in writing |
What exports cleanly from the Statuspage API and what you rebuild
The Statuspage REST API is the documented path for pulling components, incident history and subscribers out of your current page. Its limit of one request per second per token means a full pull of a large subscriber list or a long incident history takes time. Paginate every list endpoint, save each page as raw JSON with a timestamp, and run the pulls as a scheduled job outside business hours. Use a dedicated API token for the migration so the export does not compete with dashboards or other scripts. Confirm the current rate limit, pagination parameters and fields returned for subscribers in Atlassian's API documentation before you write the script.
Several things do not transfer as data. Page design, branding, logos, custom CSS, incident and maintenance templates, and email templates must be rebuilt by hand in OneUptime's status page settings. Subscriber consent records are the harder gap. An exported email address shows where a subscriber lives, not how that person agreed to receive notices or whether a double opt-in applied. Keep the exported list as a reference, but only import contacts you can document as opted in. For everyone else, send a subscription invitation through the new page and let subscribers opt in again. Ask Atlassian whether the export includes subscription source or timestamps, since that data decides how much you can carry over.
Incident history can be exported in full, but you need to decide what to rebuild. Recreate recent and customer-relevant incidents in OneUptime with their timelines, affected components and post-mortem links, since those are what subscribers will look at on the new page. Keep older records as an archive file that your team can search if a question arises. Scheduled maintenance does not carry over as a live calendar, so re-enter any future windows by hand. Map each Statuspage component to a OneUptime component before you import anything, and check the OneUptime repository to confirm which import options your release supports.
Which data and integrations to move, and which to rebuild
Statuspage holds five kinds of data and wiring: components, incident history, scheduled maintenance, subscribers and domains, plus the integrations that feed it. Each one either exports through the Statuspage API or has to be rebuilt in OneUptime, and each needs a named owner on both sides before cutover. The cards below set out the path and the owner for each item.
Components and component groups
Export the component list and its groups from the Statuspage API, then recreate each component in OneUptime as a monitored resource or status page resource. Map every Statuspage component to the check or telemetry source that proves its health, so the owner of the monitor is the same person who owns the service. Because OneUptime ingests telemetry through OpenTelemetry-based agents for servers, Kubernetes, Docker and databases, component status can be driven by monitors rather than typed in by an operator during an incident. Confirm which components should stay manual, such as third-party dependencies with no health endpoint.
Incident history and updates
Export past incidents with their timestamps, impacted components and update text through the Statuspage API, then decide how much history the new public page should show. Re-create recent incidents in OneUptime so the incident history on the status page reads correctly, and keep an archive export for audit and post-mortem reference. The communications owner signs off on wording, and the incident commander owns any open incident during cutover. Do not carry over incidents that still have unresolved status in Statuspage without closing them first.
Scheduled maintenance windows
Pull upcoming and recent scheduled maintenance from Statuspage, including affected components and notification settings. Recreate the future windows in OneUptime's scheduled maintenance feature before the old page is switched off, so customers still see planned work and their notice period is preserved. Check time zones and recurring windows, since these are the entries most often lost in a manual rebuild. The change manager owns the calendar, and the platform owner confirms that each window is visible on the new page.
Subscribers and their channels
Statuspage subscriber lists belong to the customer and carry consent records, so export them only under your data processing terms and keep the source of each address. Import subscribers into OneUptime only where the consent basis and channel (email, SMS or webhook) carry over, and send a notice inviting people to re-confirm their subscription where it does not. Confirm SMS delivery and sender setup with your provider before cutover, because OneUptime's notification channels depend on your own configuration. The privacy lead owns the consent decision, and the marketing or support lead owns the notice.
Custom domains and DNS
Plan the status.example.com record change as its own step with a rollback. Set up the custom domain in OneUptime, issue the TLS certificate, and test the page at the new address before lowering the TTL and moving the CNAME away from Statuspage. Keep the Statuspage page live during a parallel period so links in customer emails, help articles and internal runbooks still resolve. The DNS owner signs off on the record change, and the platform owner confirms the certificate and page are working before the old record is removed.
Integrations that push incidents
List every tool that posts incidents or component changes into Statuspage, including monitoring alerts, chat commands and on-call tools, and the API token each uses. Rebuild each feed as an inbound integration or webhook in OneUptime, and test it with a scheduled non-customer-facing incident before relying on it. Check that alert routing and escalation still reach the right on-call person, because OneUptime's on-call schedules and escalation policies replace any separate paging step. The integration owner rebuilds each feed, and the incident commander signs off on the test.
Migration sequence from inventory to decommission
This sequence moves public and private status pages from Atlassian Statuspage to OneUptime without breaking subscriber trust or losing incident history. Each step produces a written artifact, so the cutover and the eventual shutdown of Statuspage rest on evidence rather than memory.
Inventory pages, components, subscribers and integrations
Pull the current state of every status page through the Statuspage REST API, which is rate limited to one request per second per token, so plan the export around that limit. Record each page, its custom domain, its component groups and components, the incident history, scheduled maintenance, and the subscriber list with its channels (email, SMS, webhook, Slack). Also list every integration that posts to Statuspage, such as monitoring tools or chat bots. The step closes when you have an export manifest that counts each object type and a checksum or row count you can compare against the export later.
Build a signed-off component map
Map each Statuspage component to a OneUptime monitor, status page resource or group, and note which components have no automated check and will be updated by hand. Decide which Statuspage pages become OneUptime public pages, which become private pages, and which are retired. Have the service owners and the incident communications owner review the map. The step closes with a signed-off component map that names an owner for every component and every page, and lists the open questions about custom domains and branding.
Pilot with one internal private page
Build one internal private status page in OneUptime for a low-risk audience, such as employees, with the components from the map and an SSO login if your identity provider supports it (OneUptime's Community Edition includes SAML and OIDC single sign-on). Create a test incident and a scheduled maintenance window, then confirm that they appear correctly, that the history renders, and that the people in the pilot group can see the page. Also check how the notifications are delivered and to whom. The step closes with a pilot sign-off record listing what passed, what was changed, and who approved the result.
Run both tools in parallel
For a defined period agreed by the incident and communications leads, publish the same incidents and maintenance notices to both Statuspage and OneUptime. Post from the same source of truth, such as a single incident template, so that wording and timestamps match. Compare the two public pages after each event and log any discrepancy. Confirm that OneUptime's subscriber notifications are reaching a test list of addresses and phone numbers that you control, and that the delivery logs show success. The step closes with a parallel-run log that records each event, the discrepancies found, and the fixes applied.
Get subscriber consent before moving lists
Do not import subscriber addresses into OneUptime on the assumption that they will stay subscribed. Instead, send a message through Statuspage that explains the new page, the new sender, and how to subscribe on the new page, and ask people to confirm. Keep a record of each consent with the date, channel, and source, and exclude anyone who has not confirmed. Check the consent rules that apply to your organization and the regions your subscribers are in with your legal or privacy team. The step closes with a subscriber consent record that shows which contacts confirmed and which were left out.
Cut over DNS and subscriber communication
Point the status page hostname to OneUptime during a window agreed in advance, and verify the TLS certificate, the custom domain, and the public page from several networks. Send the final notice on the old Statuspage and the first notice from the new page, so subscribers know where updates will come from. Switch integrations from Statuspage to OneUptime one at a time, testing each with a sample event. The step closes with a cutover checklist signed by the incident lead, containing the DNS change record, the certificate check, and the integration test results.
Decommission Statuspage after retention and audit needs
Keep Statuspage read-only until the export has been verified and the incident history, subscriber records and consent records have been stored where your retention and audit rules require. Confirm with compliance or internal audit what they must keep and for how long, and ask the Atlassian account owner what happens to data when a subscription ends. Revoke API tokens, remove integrations, and cancel the subscription only after those checks pass. The step closes with a decommission record listing the archived artifacts, their storage location, the approvers, and the date the subscription ended.
Moving subscriber notifications without losing consent
Some subscribers may have a clear record of how and when they opted in to status updates, such as a signup form with a timestamp, a double opt-in confirmation or a documented consent field. Records like these are the strongest basis for carrying subscribers into a new notification system, but the consent belongs to the original collection context, and you should confirm that the new use of the address, the new sender and the new data store are covered by the notice they saw at signup.
- Export what Statuspage holds: Pull subscriber records through the Statuspage API, respecting its one request per second limit per token, and keep the export file under the same access controls as other customer data.
- Match each address to its evidence: Join each subscriber to the opt-in record, including date, source, notice version and confirmation method, before anything is imported.
- Keep the original purpose: Import only subscribers whose opt-in covers status and incident notices, and exclude anyone whose consent was for marketing.
- Record the import: Log the source file, the import date and the count of records loaded into OneUptime so the basis can be shown later.
- Honor unsubscribes: Carry over every suppression entry from Statuspage before sending the first notification, so opt-outs are not re-enabled.
Before importing, ask your privacy or legal team to confirm the lawful basis for each category of subscriber and the opt-in evidence they accept.
Importing a subscriber list does not carry consent over automatically. An address that was added by an administrator, collected for another purpose or stored without a record of its origin should not be treated as having agreed to receive notices from OneUptime. The safer path is to leave these addresses out of the import and send each one a fresh invitation that asks them to subscribe.
- Separate the list first: Mark subscribers with missing, partial or disputed opt-in records as re-invite candidates instead of importing them.
- Send a clear invitation: Explain who is sending the notices, what they will receive, how often they can expect messages and how to unsubscribe, in plain language.
- Require an affirmative action: Activate a subscription only after the recipient confirms it, and store the confirmation with a timestamp.
- Plan for lower response: Expect that many re-invited subscribers will not confirm, and tell the business owners of the status page before the switch.
- Keep a parallel notice on the old page: Where policy allows, point the Statuspage subscriber page to the new invitation during the transition period.
Ask your privacy or legal team whether re-invitation itself must meet specific requirements for the jurisdictions where your subscribers live.
Private status pages for employees or partners are usually a different case from public subscriber lists. Statuspage charges for authenticated subscribers, so many organizations hold internal audiences in the same list. In OneUptime, the Community Edition includes SAML and OIDC single sign-on, which allows internal audiences to be governed by your identity provider rather than by a separately imported subscriber list.
- Move access to the identity provider: Define the internal audience as a group in your identity provider and map that group to access on the private status page.
- Use SAML or OIDC: Configure single sign-on in OneUptime with the protocol your identity provider supports, and confirm the exact setup steps in the OneUptime documentation for your release.
- Do not import employee contacts as subscribers: Let people sign in with their corporate identity instead of copying their email addresses into a list.
- Review group membership: Remove access when people leave or change roles, because the identity provider becomes the source of truth.
- Check what the Community Edition covers: Automated provisioning through SCIM and audit logs are listed as Enterprise Edition features, so confirm whether you need them before deciding.
Confirm with your identity and security teams which groups should have access and how removal will be enforced.
What drives migration cost and duration
This table lists the factors that move the effort of moving from Statuspage to OneUptime, why each one matters and how to reduce it. Use it to scope your own migration and to prepare the inputs for a fixed-scope quote, since no duration or price is implied by any row.
| Driver | Why it moves effort | How to keep it down |
|---|---|---|
| Number of pages and custom domains | Each public or private page needs its own branding, domain, DNS and certificate work, and each must be re-verified before switching. | Consolidate pages where audiences overlap, and list every custom domain up front so DNS changes are planned in one window. |
| Component count and nesting | Statuspage components and groups must be mapped to OneUptime monitors and status page resources, and nested structures need manual checks. | Export the component tree first, drop retired components, and agree the mapping in writing before rebuilding. |
| Subscriber volume and consent quality | Subscriber lists must be exported and checked for consent before any notification is sent, and records without clear consent cannot simply be imported. | Confirm which subscribers opted in and through which channel, keep only those records, and ask the vendor how subscriber data is exported in your Statuspage plan. |
| Integrations to rebuild | Webhooks, chat alerts, ticketing links and any custom tooling that posts to Statuspage must be re-pointed to OneUptime endpoints and tested. | Inventory every inbound and outbound integration, and prioritize the ones that publish incident updates during an outage. |
| Private and SSO audiences | Private pages need audience groups and single sign-on configured against your identity provider, and access rules must be tested per group. | Define audience groups before migration, use the SAML or OIDC single sign-on that Community Edition includes, and test each group with real accounts. |
| Hosting choice | Docker Compose on a single Debian, Ubuntu or RHEL server is simpler to stand up, while the Helm chart the project recommends for production adds cluster operation, storage and upgrade work. | Confirm which option fits your platform team's skills, and ask the implementer to document backup, restore and upgrade procedures for the chosen option. |
| Enterprise features required | SCIM provisioning, audit logs, compliance dashboards, priority support and data residency belong to the Enterprise Edition, which is priced through sales, so their need changes both licensing and configuration. | List required features against the Community Edition before scoping, and request Enterprise pricing and terms in writing if any are mandatory. |
Questions buyers ask before moving from Statuspage to OneUptime
Can our team migrate from Statuspage to OneUptime in-house?
Often yes, if one or two engineers can own the work and have time for it. OneUptime's Community Edition is Apache 2.0 licensed and includes branded public and private status pages, incident history, scheduled maintenance and subscriber notifications, so the functional scope of a status page migration is contained. The work that usually decides the outcome is not the software install but the export of components, incidents and subscribers, the rebuild of page layout and custom domains, and the change communication to users. If your team has not run a self-hosted service before, consider a fixed-scope engagement from DeployOpen for the installation, hardening and cutover, and keep the content work in-house.
What does the migration need from our engineering and operations team?
The team needs to own four things: hosting, data export, page content and communication. Hosting means running OneUptime with Docker Compose on a single Debian, Ubuntu or RHEL server, or with the Helm chart that the project recommends for production, and keeping it patched and backed up. Export means calling the Statuspage REST API within its rate limit of one request per second per token. Content means mapping Statuspage components to OneUptime monitors and rebuilding pages. Communication means telling subscribers about the change. Ask OneUptime which deployment path fits your platform before you commit to a design.
Can we import our Statuspage subscriber list into OneUptime with consent?
Only if the subscriber list carries a clear record that each person opted in to receive notifications from you, and that record is kept with the export. Statuspage subscribers signed up for specific pages and components, so the consent basis should be checked before any address moves. Bulk-importing addresses that subscribed to a different service or a different page is the main risk. A safer path is to export the subscribers, filter them to those with an active opt-in, and send a short notice on the old page asking subscribers to re-subscribe on the new OneUptime page. Confirm with your privacy or legal team how your jurisdiction treats consent carried over between providers.
How should we run Statuspage and OneUptime in parallel during cutover?
Run both pages for a defined overlap, publish every incident to both, and switch the public domain last. Because OneUptime monitors websites, APIs, ports, SSL and DNS, you can point its monitors at the same services that feed Statuspage, so both systems see the same events. Keep the Statuspage page live until the OneUptime page has been tested with a scheduled maintenance notice and a test incident. Confirm that subscriber notifications from OneUptime reach email and SMS recipients correctly before DNS changes. Document the overlap window and the rollback step in the change ticket.
What does OneUptime Enterprise add, and do we need it for status pages?
For most status page migrations the Community Edition is enough. The Enterprise Edition adds SCIM provisioning, audit logs, compliance and instance health dashboards, priority support and data residency, and it is priced through sales. Community Edition already includes SAML and OIDC single sign-on, which covers many private status page needs. Consider Enterprise if your auditors expect audit logs for status page changes, if you need SCIM to deprovision staff automatically, or if you need contractual support. Note that the Enterprise code sits in the ee/ directory under a separate license, so review that license before deployment.
How do the cost drivers compare with Statuspage?
The cost difference comes from who pays for what, not from a single price. Statuspage charges a recurring plan that depends on subscribers, team members and page type. Self-hosted OneUptime removes subscriber and seat caps from the software side, but you pay for the server, storage, backup, email and SMS delivery, and the engineering time to upgrade and patch. Ask any implementer for a fixed-scope quote that lists the installation, data export, page rebuild, cutover support and any retainer for upgrades separately. Your own hosting and messaging volumes will decide the recurring cost more than the license.
What should we confirm with OneUptime before committing to the migration?
Confirm the items that affect your design, not only the feature list. Ask which OneUptime release you should deploy, since the project publishes versions such as 14.0.70 on its releases page, and check its upgrade path. Confirm how custom domains and TLS are configured per status page, how subscriber notifications are delivered, and which email and SMS providers you must supply. Ask how the Statuspage export maps to OneUptime objects and whether there are gaps in component history. Finally, confirm which features you need from the Enterprise Edition and get that answer in writing.
What usually goes wrong and how to prevent it
Most failed status page migrations do not fail on the software. They fail on subscribers, duplicate incidents, export limits, DNS records and access rules that nobody owned during the switch. Each card below names one of these risks and the step that prevents it.
Subscribers lost during cutover
Statuspage holds the subscriber list, and that list cannot be assumed to move with the page. Export subscribers through the Statuspage API, then confirm each one has a consent record before re-importing anything into OneUptime. Subscribers who never opted in to the new tool must not be added by default. Send one notice on the old page explaining where updates will move and how to subscribe again.
Duplicate incidents across two tools
For a period, the same incident may be posted on Statuspage and on OneUptime, and subscribers receive two notifications or conflicting statuses. Pick a cutover date, freeze new incident creation on Statuspage after that point, and keep any open incident on one tool until it closes. Write down which tool is the source of truth for each open incident.
Export stalled by the API rate limit
Statuspage's REST API allows one request per second per token. A full export of components, incident history and subscribers can take far longer than expected if it is run in a single loop without pagination control or retries. Plan the export as a scripted job that logs each page, resumes after a failure and saves raw responses so a rerun does not start from zero.
DNS and custom domain mistakes
Status page domains such as status.example.com usually point at Statuspage through a CNAME record. Moving the domain before OneUptime is serving the same certificate and branding leaves subscribers with a broken page or a certificate warning. Lower the record TTL before the change, configure the custom domain and TLS on OneUptime, verify it from outside your network, and keep the old record ready to restore.
Private audiences left without access
Internal or audience-restricted pages on Statuspage often rely on subscriber lists or invitations that do not map one to one onto OneUptime access. Employees may lose visibility during an outage, which is the worst time to find out. Before cutover, list every private audience, decide how each group authenticates, and test sign-in with a real account from each group using the single sign-on your identity provider supports.
Inherited on-call and escalation settings
Statuspage pages are often wired to alerts from Opsgenie, PagerDuty or chat integrations that someone set up years ago and nobody reviewed. Copying those integrations into OneUptime can page the wrong team or nobody at all. Rebuild each on-call schedule and escalation policy from a named owner's list, send a test alert to each route, and retire the old integration only after the test succeeds.
How the migration differs by team size and starting point
A small team with one public status page usually has a short list of components, a modest incident history and a single subscriber list. The migration is mostly a sequencing exercise: export what exists, rebuild one page in OneUptime, test it, and then switch the public address. Little needs to be re-architected, but the subscriber step carries the most risk because people opted in to a specific sender and address.
- Export first: Pull components, incident history and subscribers through the Statuspage API before you change anything in the live account.
- Rebuild one page: Recreate the components and branding on a single OneUptime status page, then check the incident history and scheduled maintenance display correctly.
- Decide on subscribers early: Choose whether subscribers re-confirm on the new system or whether you carry them over, and document that decision with your legal or communications owner.
- Keep the old page live during overlap: Run both pages for a period so customers can see the new one before the DNS switch.
- Confirm notification channels: Check that email and any SMS delivery you rely on are configured on your own instance before the cutover.
Before cutover, confirm the consent basis for every subscriber you plan to import with your own privacy or legal team.
A larger organization often runs many public pages, several regional or product-specific pages and private pages for internal or partner audiences. The sequence changes because the inventory is the hard part: the team has to map which page owns which components, which audiences see which incidents and where custom domains point. Private audiences also need an access model that replaces the hosted audience controls.
- Inventory pages and audiences: List every page, its custom domain, its components and its subscriber groups before deciding anything.
- Map components to owners: Assign each component to a team so that incident updates on OneUptime reach the right people in the right order.
- Plan private page access: Decide how internal audiences authenticate, for example through single sign-on with SAML or OIDC, which OneUptime's Community Edition includes.
- Migrate in waves: Move low-risk internal pages first, then customer-facing pages, so that problems surface on less visible pages.
- Handle identity mapping: Confirm how employee identities from your directory map to page permissions before you invite users.
Ask your team which pages carry contractual or regulatory notice obligations, because those pages should move last and with the most testing.
A regulated organization, such as one in banking, healthcare or public sector work, usually cannot treat the status page as a simple web asset. Auditors may ask who changed an incident, when a subscriber was notified and where the data is held. OneUptime's Enterprise Edition adds SCIM provisioning, audit logs, compliance and instance health dashboards, priority support and data residency, and it is priced through sales, so the decision point is whether those features are needed before the migration starts.
- Confirm edition requirements first: Decide whether Community Edition controls are enough or whether Enterprise audit logs and SCIM are required for your evidence.
- Set data residency before import: Choose where the instance runs and where subscriber data is stored, and ask the vendor which residency options apply to your edition.
- Plan the audit trail: Document how incident history, notification records and access changes will be retained across the old and new systems.
- Approve the consent transfer: Have legal sign off on how subscriber consent records move, and whether subscribers must re-opt in.
- Schedule change control: Run the cutover through your formal change process, with rollback steps and named approvers.
Before you commit, ask the vendor in writing which features are included in each edition and which compliance artifacts they provide, and ask your auditor which evidence they expect.
How DeployOpen scopes and runs a Statuspage to OneUptime migration
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside the client's own infrastructure, including the cloud accounts, data centers or air-gapped networks where the OneUptime instance will run. For a Statuspage migration, that means the work covers the OneUptime deployment itself, the export and re-creation of public and private status pages, the mapping of components to monitored resources, the subscriber notification plan and the operating runbook. DeployOpen does not issue audit reports or certifications, and it does not claim any vendor partnership for OneUptime or Atlassian. Those points should be confirmed in writing before scoping starts.
Most engagements are fixed-scope. Before work begins, the parties agree in writing on the deliverables, such as the hosting target (Docker Compose on a single Debian, Ubuntu or RHEL server, or the Helm chart the project recommends for production), the list of pages and custom domains to move, the subscriber migration method and the acceptance checks for DNS cutover. A quote follows from that written scope, so the variables that move the price are the number of pages, components, subscriber lists, integrations to rebuild and any compliance evidence the client needs collected. Ask for each of these to be listed as a separate line in the quote so that you can see what is included and what is optional.
Ongoing support, upgrades and continuous testing are available as retainers once the new status page is live. This matters for a status page because OneUptime releases change frequently, so a named owner should review each upgrade against the staging instance before it reaches production. Confirm during scoping who holds the administrator role, where backups of the database and configuration are stored, how the team will test restores, and what happens to the Statuspage account during the parallel run. Those answers should be written into the statement of work before any subscriber is contacted.
