Open data portal RFP questions for vendors

Open data portal RFP questions to ask before you choose a partner

If your public body or institution must publish open data on its own infrastructure, you need to compare vendors and implementation partners on equal terms. This section gives the questions to put in a brief, what a good answer looks like and the red flags that should slow you down. Send the same written brief to every bidder, and ask every bidder to tie each answer to a named platform version, such as a specific CKAN release and its support window. Score the responses against the brief itself, not against the sales deck or the demo, so that a polished presentation cannot outweigh a vague answer on hosting or licensing.

CKAN is open source under the GNU Affero General Public License v3.0, so there is no software subscription to buy. That single fact is why your questions must separate software from services. Ask each bidder to price and describe the platform, the implementation, the hardening, the backup and upgrade routine and the ongoing support as distinct lines, and to state which of them they would perform and which your own staff would own. A bidder who quotes one bundled figure without that split is asking you to accept an unknown scope. Ask for the CKAN minor and patch version they will deliver, and confirm with the project's release policy how long that version receives security fixes.

Several questions carry the most weight, and they are the ones bidders most often answer loosely. Ask who holds licence obligations for any extensions they add, and whether AGPL-3.0 obligations apply to changes they make to the running portal. Ask how existing datasets will move in, including metadata mapping, DataStore loading and the handling of files that fail validation. Ask for the hosting model, the security evidence they can produce (such as test reports and configuration baselines, not certificates they cannot show), and the support terms after go-live with response expectations written into the fixed scope. Treat any bidder who promises certification, guaranteed compliance or unlimited changes within a fixed price as a red flag, because a compliance assessment is performed by independent auditors and a fixed scope must name its exclusions.

Which platform, version and edition questions reveal real fit?

Which CKAN version does the bidder propose, and why that minor release?

The bidder should name a specific release, such as CKAN 2.12.0, which was released on August 26, 2026, alongside maintenance releases 2.11.6 and 2.10.11 on the same day. Ask why that minor line fits your timeline, which extensions it supports, and whether the proposal starts on the latest patch. A good answer explains the choice in terms of your requirements, not a default. Ask the bidder to confirm the exact patch number they will deploy and the date they will verify it against the release page.

How does the CKAN release policy affect our patching obligations?

CKAN targets about two minor releases a year. The tech team supports the latest patch of the current minor version and the previous minor version for security and bug fixes, and older patches lose support once a newer patch is out. Ask the bidder to state which patch line the portal will run, how they will track new patches, and how quickly they will apply security fixes in your environment. Also ask whether patching is included in the fixed scope or sits in a support retainer, and what the quote assumes about your change windows.

How will the bidder handle minor-release upgrades that break compatibility?

CKAN patch releases do not break backwards compatibility and exclude schema changes and new features. Minor releases may include backwards-incompatible changes, so each minor upgrade needs its own plan. Ask the bidder how they will review release notes, test custom extensions and themes on a staging copy, handle database migrations, and roll back if an upgrade fails. A strong answer names the test data, the owner of each step and the acceptance criteria, and states whether the upgrade is a separate fixed-scope piece of work or part of ongoing support.

Which CKAN extensions are in scope, such as ckanext-dcat and ckanext-saml2auth?

Ask for a written list of every extension, with the version and the requirement it serves. ckanext-dcat provides DCAT-AP v1, v2 and v3 schemas, DCAT RDF endpoints and an RDF harvester, and is supported on CKAN 2.10 and 2.11, so confirm that the chosen CKAN version is covered. ckanext-saml2auth covers SAML single sign-on for staff, which should be checked against your identity provider and the bidder's testing plan. For each extension, ask whether it is in the fixed scope, who maintains it after go-live, and how the bidder will test it against each upgrade.

Which Python, PostgreSQL, Solr and Redis versions should a good answer name?

A credible answer names the runtime and service versions instead of saying the stack is standard. For a source install, CKAN requires Python 3.10 or newer, PostgreSQL 12 or newer, Solr 9 (recommended) or Solr 8, and Redis, with uWSGI and Nginx recommended for production. Ask the bidder to state the exact versions they will deploy, the operating system, and whether Solr and Redis run from Docker images tagged for the CKAN version. Also ask how they will track end-of-life dates for each component during the support period.

Does the bidder use XLoader or legacy DataPusher for DataStore loading?

The bidder should use XLoader, which is the officially supported tool for loading uploaded or linked files into the CKAN DataStore. DataPusher is now legacy, so a proposal that relies on it creates a maintenance question. Ask which loader the design uses, how large files and time series will be processed, how failed loads are reported to publishers, and how the DataStore's separate PostgreSQL database and its read-only user are configured. Ask the bidder to show the test results for a representative file before go-live.

How does the bidder's version answer change the fixed scope and cost?

Version and extension choices drive the amount of testing, the number of upgrade cycles inside the support period and the custom code that must be maintained. Each extra extension, custom theme or harvester adds build, test and upgrade effort, and each planned minor upgrade adds a fixed piece of work. Ask the bidder to separate one-time work (installation, extension configuration, initial testing) from recurring work (patch application, minor upgrades, extension maintenance). DeployOpen scopes engagements in writing before work starts, so ask any bidder to show these items as separate lines in the quote.

How should the RFP test migration of existing datasets?

An existing CKAN portal is the simplest starting point, but an upgrade still moves schema, DataStore tables and extensions. Ask the vendor to confirm the current and target CKAN versions and the path between them, since CKAN minor releases may include backwards-incompatible changes while patch releases do not. Ask how custom extensions, scheming profiles and harvesters are tested against the target version before cutover.

Version path: State the source minor version, the target minor version and every intermediate step the vendor plans to run, with the database and Solr changes each step needs.
DataStore tables: Ask how DataStore tables are dumped, restored and re-indexed, and how the read-only database user is recreated and tested.
Persistent URLs: Ask how dataset and resource URLs, API consumers and existing DCAT endpoints keep working after the upgrade, and which redirects are written.
Parallel run: Ask whether a staging copy runs alongside production for a defined period, and how new records created during the parallel run are reconciled.
Rollback: Ask for a documented rollback point, the database backup used to reverse the change, and the time window in which rollback is still safe.

Check that the vendor's acceptance tests compare record counts, resource counts and API responses between the old and new instances, and that the results are written into the migration inventory.

Which hosting model questions matter for data location and operations?

Each hosting model moves control of data, backups and search indexes to a different party. The questions below ask each bidder who holds the accounts, where Solr indexes and backups sit, and how the portal leaves that model if the buyer needs to move. Ask every bidder to price each option in writing, because cost and staffing change by model.

Buyer-owned cloud account

Ask whether the buyer's own cloud subscription holds the virtual machines, managed PostgreSQL, storage buckets and backups, with the bidder working through delegated roles. Confirm which operating systems the stack runs on, since the CKAN install guide covers Ubuntu 20.04 and 22.04 64-bit and source installs work on other distributions such as Red Hat, Fedora and CentOS. Ask who holds root and database credentials, where the Solr index is rebuilt after a restore, and how the buyer takes the full stack to another account. Price the internal staff time this model leaves with the buyer.

Government or institutional data centre

Ask whether the portal runs on hardware the buyer's own data centre team operates, inside its network segments and under its change control. Check whether the bidder can work through the buyer's jump hosts, and where backups go, including whether an off-site copy stays inside the same jurisdiction. Ask who patches the operating system, PostgreSQL, Solr and Redis, and how Solr and Redis are deployed, either as packages or as container images tagged per CKAN version. Confirm the exit path to another data centre or to a cloud account.

Air-gapped network

Ask how the bidder delivers the CKAN release, extensions, Python packages and container images across the air gap, and who verifies each transfer before import. Confirm that Solr, Redis and PostgreSQL run without any outbound calls, and that the DataStore read-only user and the DCAT endpoints still work offline. Ask how security patches reach the portal on a fixed schedule, and where the Solr index and backups are stored. Expect update cycles and staffing to be slower and costlier than in connected models, and ask the bidder to price them separately.

Managed hosting by the vendor

Ask the vendor which named staff hold administrative access, where the hosting facility is located, and whether the buyer receives its own database and Solr instances rather than shared ones. Ask for the backup location, retention period and the restore test schedule, all in writing. Check which CKAN minor and patch versions the vendor runs, and whether it applies security patches to both the latest and previous minor versions. Ask for the exit process, including a full export of datasets, metadata and users, and the format used.

Multi-tenant SaaS

Ask whether the buyer's datasets share a database, search index or storage container with other customers, and how tenant separation is tested. Confirm which party can read the DataStore, where Solr indexes are stored and whether backups are copied to other regions. Check whether the provider supports the DCAT-AP exports and harvesting the buyer needs, and whether custom extensions are allowed. Ask for the exit terms in writing, including how long the provider keeps data after cancellation and how the buyer receives its metadata and files.

What security evidence should a bidder provide before award?

Ask every bidder to separate what they state from what an independent party has verified. A bid that says the portal is hardened is an assertion. A hardening baseline mapped to the platform's configuration, a penetration test report from a tester who does not work for the bidder, and a dated remediation log for its findings are evidence. Require the baseline for the CKAN application server, the reverse proxy, the PostgreSQL and Solr hosts and the Redis instance, and ask how each setting is enforced after go-live, not only at installation. Request TLS design details: supported protocol versions, certificate issuance and renewal, and how the Nginx and uWSGI layers terminate encryption. Confirm the authentication design too, including how staff sign in through SSO using SAML or OIDC against your identity provider, with the ckanext-saml2auth extension if SAML is chosen. Confirm the bidder will test that login path, not only describe it.

Ask how secrets are stored and rotated, including the CKAN configuration file values, database credentials and API tokens, and whether any of them appear in source control or deployment logs. Ask for the separation of DataStore roles in practice: the write user should be the only account that can alter tables, and the read-only user should be the only account the public Data API depends on. Ask the bidder to show the grants, not describe them. For logging, request the events captured for sign-ins, dataset edits, permission changes and API access, where they are sent, how long they are kept and who can read them. Finally, ask for the vulnerability management cadence, the patching approach for CKAN releases and the penetration test scope and date.

DeployOpen runs security testing, but it does not issue audit reports, attestations or certifications, and neither does any implementation partner. Ask every bidder, including DeployOpen, to name the independent assessor who will review the portal and to state which controls that assessor will evidence for your own compliance assessment. Confirm in writing which evidence the bidder will hand over at handover, which artifacts remain the client's responsibility, and whether re-testing after remediation is in the fixed scope. Treat a missing name for an independent reviewer as a gap to resolve before award.

Which accessibility and metadata standards should the RFP require?

Should an open data portal RFP require WCAG 2.1 Level AA conformance?

Yes, for US state and local government buyers, the ADA Title II web rule requires web content and mobile apps to meet WCAG 2.1 Level AA. An interim final rule published April 20, 2026 set compliance dates of April 26, 2027 for entities with 50,000 or more people and April 26, 2028 for smaller entities and special districts. Ask the bidder to state whether the portal and any custom theme are tested against WCAG 2.1 Level AA, which parts of the site are covered (dataset pages, search, API documentation, downloads and admin screens), and which tools and manual checks they use. Also ask whether the work is included in the fixed scope or priced separately. Confirm the compliance date that applies to your entity with counsel, because the rule text is the reference, not the vendor's summary.

Who should test portal accessibility, and what results should the buyer receive?

The bidder should name who performs the testing, and the buyer should receive the results in writing. Ask whether testing is done by the implementer's own staff, an independent accessibility specialist, or the buyer's own testers, and whether people who use assistive technology take part. Request the audit method, the list of pages and templates tested, a defect log with severity and status, and a retest record after fixes. Ask how issues found after go-live are reported and fixed under the support terms. DeployOpen prepares systems and evidence for compliance assessments, but it does not issue audit reports or certifications, so ask the bidder to confirm which independent review, if any, the buyer must commission.

Which DCAT-AP or national profile should the portal output?

Name the exact DCAT-AP version or national profile your catalog must publish, because the requirement comes from your national or regional rules and from the catalogs that will harvest your records. Ask the bidder which profile they will map CKAN fields to, and whether they will use the ckanext-dcat extension, which provides DCAT-AP v1, v2 and v3 schemas, DCAT RDF endpoints and an RDF harvester. Confirm the supported CKAN version, since ckanext-dcat is supported on CKAN 2.10 and 2.11, and check that the bidder plans to upgrade the extension when CKAN moves to a newer minor release. Ask for the field mapping as a written deliverable before build starts.

How should the bidder validate RDF endpoints and harvested records?

The bidder should show a repeatable validation method, not a one-time check. Ask for the validator or shapes they will run against RDF output, the test datasets they will use, and the report format. Request a test harvest from a sample external catalog and a test export to a receiving catalog, with a record of every rejected or altered field. Ask how they will handle datasets with missing required properties and whether validation runs in the build pipeline, after each import, or on demand. Confirm that the validation results will be delivered to your team and kept as evidence of the output's quality.

Does the bidder cover the cost of accessibility and metadata work?

Accessibility and metadata work is a build cost, and it recurs when standards change. The one-time part covers the theme audit, template fixes, the metadata mapping and the first validation cycle. The recurring part covers retesting after releases, updates to the profile and extension, and fixes for new content types. Ask the bidder to list these items as separate lines in the written scope, with who performs each task and what is included in the fixed price. Ask what is excluded, such as custom widgets or third-party embeds, because those often add effort. Quotes follow from the written scope, and DeployOpen does not publish a price list.

What should a metadata validation checklist include before go-live?

A useful checklist covers both the standard and your own rules. Include these items:

Required fields from the chosen DCAT-AP or national profile are populated and pass validation.
Controlled vocabularies, such as licence and format values, use the codes the profile expects.
Dataset, resource and organization identifiers are stable and resolvable through the RDF endpoints.
Harvested records from external catalogs are mapped and flagged where fields are missing.
Accessibility checks cover the dataset pages, search results and documentation pages.

Ask the bidder to deliver this checklist with completed results and a sign-off record. Keep the checklist as part of the handover documentation so your team can rerun it after upgrades.

Can the bidder maintain accessibility and metadata compliance after launch?

The bidder can usually maintain both, but the terms must say so in writing. Ask whether post-launch support includes retesting after CKAN patch and minor releases, updates to the metadata extension, and regression checks after theme changes. CKAN patch releases do not break backwards compatibility, while minor releases may include backwards-incompatible changes, so ask how the bidder plans upgrades and tests them. Ask for the response process when a validation failure or accessibility defect is found, and whether those tasks sit in a support retainer or a separate change request. DeployOpen offers ongoing support, upgrades and continuous testing as retainers.

How should support terms after go-live be written into the brief?

The sequence asks each bidder to answer support questions in the order the work happens, so the brief can compare what is one-time, what recurs, and what starts a paid change. The result is a support schedule that a buyer can price and hold the bidder to.

Define the hypercare window and exit criteria
Ask the bidder to state how long hypercare runs after go-live, who staffs it, and which conditions close it, such as a clean run of scheduled harvests, a completed user acceptance sign-off and no open severity-one defects. Confirm whether hypercare is included in the fixed scope price or quoted separately as one-time effort. Done when the brief holds a written start date trigger, a named exit checklist and the price line that covers it.
Set incident response roles and hours
Require a named escalation path with the roles on each side: the bidder's first-line responder, the platform engineer who handles CKAN, Solr, PostgreSQL and Redis faults, and the buyer's portal owner. Ask for the hours of cover, the channels for reporting, and the response targets written in plain terms for each severity level. Ask the bidder to say which targets it has priced and which it will only attempt. Done when the response matrix is attached to the contract and each target has a matching price line in a retainer or an explicit exclusion.
Agree the CKAN patch and minor upgrade process
Ask how the bidder will track CKAN releases, including the current minor version and the previous minor version that the CKAN tech team supports, and how it will apply patch releases, which the project states do not break backwards compatibility. Ask separately how minor releases are handled, since the project states they may include backwards-incompatible changes, and require a staging rehearsal before any production change. Ask whether each upgrade is one-time project effort or covered by a recurring retainer, and what triggers a change request. Done when the brief specifies a written upgrade calendar method, a staging gate and a rule for when a minor upgrade becomes a separate scope item.
Test extension compatibility before each change
List every extension in scope, such as the DCAT, SAML single sign-on and DataStore loading components, and require the bidder to state how each one is tested against a new CKAN version before promotion. Ask which extensions have a supported version for the CKAN release in use, and who fixes or replaces an extension that no longer works. Treat extension fixes after an upgrade as a change request unless the retainer covers them. Done when the bidder has returned a compatibility test list, an owner for each extension and a stated rule for who pays for remediation.
Run scheduled backup and restore tests
Ask for the backup scope (database, DataStore database, uploaded files, search index configuration and configuration files), the frequency and the retention period the bidder proposes, and where copies are stored inside the buyer's infrastructure. Require a documented restore test on a schedule the buyer approves, with a written record of what was restored, how long it took and what failed. Confirm whether restore tests are part of the retainer or a one-time handover activity. Done when the buyer holds a signed restore test report and the backup method is listed in the runbook.
Hand over runbooks and train the operators
Require the bidder to deliver runbooks for installation, routine operations, harvest and DataStore loading failures, search index rebuilds, certificate renewal and restore, each tied to the systems in the buyer's environment. Ask who trains the buyer's staff, how many sessions are included in the fixed scope and whether knowledge transfer continues after hypercare ends. Ask what the bidder will do if the buyer's operators change a configuration outside the runbook. Done when the buyer's operators have run a restore and a patch in a rehearsal, and the runbooks are stored in a location the buyer controls.
Define retainer scope and change request triggers
Ask the bidder to split support into three lists: one-time work already in the fixed scope, recurring retainer items with the response targets each one carries, and events that open a separate change request. Typical triggers to name include a new extension, a new data source, a new metadata profile, a platform upgrade beyond the agreed calendar and a request to change the hosting model. Ask how the bidder prices each change request and how long it will take to issue a quote after a request. Done when the brief contains a single support schedule that lists each service, its frequency, its price basis and its change trigger.

How do you define a fixed scope that holds up in the contract?

Most implementation engagements are fixed-scope, which means the scope, deliverables and timelines are agreed in writing before any work starts. Ask each bidder to list deliverables as testable items rather than general areas of work. For a self-hosted CKAN portal, that list should name the installed environment (the hosts, database, Solr, Redis and web tier, with versions), a configured DataStore with XLoader for loading uploaded files, the DCAT output endpoints and their validation results, SSO wired to your identity provider, migrated datasets with record counts per source, documentation, and training for publishers and administrators. Each item should have an acceptance check the buyer can run, such as a count reconciliation between the legacy catalog and the new one, or a test login by a named staff group.

Ask the bidder to state what is excluded. Common exclusions in portal work include data cleansing of legacy records, custom theme design beyond an agreed scope, extensions that do not yet exist, load testing beyond an agreed profile, and ongoing content publishing. Ask how new requests are priced once the scope is signed, who approves a change, and how a change affects the timeline. Ask for the change request process in writing, since this is where a fixed scope usually drifts. Also ask what the buyer must supply: named data owners who approve each dataset, identity provider access and test accounts, DNS and certificate decisions, hosting access, and staff who sign off each deliverable. Missing buyer inputs are a frequent cause of delay, so the bidder should show which dependency each milestone relies on.

A quote without a written scope cannot be compared. Two proposals with different totals may cover different migrations, different acceptance tests or different support windows, and the lower number is often the one that leaves work out. Before you compare prices, put every bid against the same list of deliverables and exclusions, and ask each bidder to confirm which CKAN release line and extension versions they will install, since those choices affect upgrade effort later. Treat any term the bidder cannot express as a testable item as an open risk that you must price or remove before signing.

Which vendor answers should worry the buying team?

Vendor answers to an open data portal RFP often reveal more than the proposal's feature list. The six patterns below show where a vague answer hides a support, security or cost problem after go-live. Each card names the follow-up question to put to the vendor in writing.

No CKAN version or release policy

A proposal that says only "we run CKAN" gives you no way to judge upgrade effort or security exposure. CKAN supports the latest patch of the current minor version and the previous minor version, and outdated patch releases lose support once a newer patch is out. Ask which exact version the vendor will deploy, which minor line it will follow, and how it will apply patch releases within a stated window. Ask what changes in minor releases, since those may be backwards-incompatible.

Compliance certification claimed without a report

Be wary of any vendor that says its hosting or platform is "certified" without naming an independent auditor's report or certification body. Implementation partners prepare systems and evidence for assessments but do not issue audit reports or attestations. Ask for the specific report, its scope, its date, and whether it covers the environment that will host your portal. If none exists, ask which controls the vendor will document for your own assessment.

Unclear who holds cloud accounts and backups

Your portal's data, credentials and backups should sit in accounts you control. If a vendor will not state which party owns the cloud tenancy, the encryption keys, the backup vault and the administrator credentials, you cannot confirm data residency or exit terms. Ask for a written list of accounts and roles, who holds root or break-glass access, where backups are stored, and how you would take full control of them at contract end.

Migration without a record count check

Migrating an existing catalog into CKAN means moving datasets, resources, organizations and metadata that often do not map cleanly. A migration plan that does not include a reconciliation step cannot show that nothing was lost. Ask for source and target record counts per dataset type, a sample of checked records, a list of fields that will not map, and the sign-off step before cutover. For structured resources, ask how DataStore loads will be verified, since XLoader is the supported loader and DataPusher is legacy.

Support promised without written response terms

"We will support you" is not an operating commitment. Support after go-live needs defined channels, hours, response and restore targets, severity definitions, and who applies CKAN patch and security releases. Ask for the support schedule in the contract, the escalation path, the named staff roles, and what happens when a CKAN minor release arrives. Retainers for ongoing support and upgrades are a separate line item, so confirm whether they are included in the quote.

Quotes that cannot be compared

When each bidder defines the work differently, the lowest price tells you little. A fixed-scope quote should list the deliverables, the environments, the integrations, the metadata standards and the testing included, along with the acceptance criteria and the dates agreed in writing. Ask every bidder to answer the same scope sheet, and ask what is excluded, what triggers a change request, and how change requests are priced. Vendors that refuse to put scope in writing before work starts are a risk in themselves.

How to score bidder responses against the brief

This table sets out what a strong bidder answer contains for each brief criterion, the evidence to request, and where the buying team should set its own weight. Weights are a decision for the buyer, so the table does not fix numbers; use it to agree the weighting before responses arrive, then score each answer against the same evidence list.

Criterion	What a strong answer contains	What to request as evidence	Weight the buying team sets
Platform fit	Names CKAN as the proposed platform or explains why another option fits, with the edition, version and extensions it would deploy and a plan for upgrades between minor releases	Installed version and extension list for a comparable deployment, the upgrade plan for the current minor and previous minor release, and a reference to the release policy	Decision for the buyer, based on how much the portal must match existing CKAN estates and extensions
Licence clarity	States the licence of CKAN and each extension, confirms that the buyer receives the source and can run it without per-user fees, and identifies any obligations under AGPL-3.0 for modified code	Written licence inventory for every component, a statement on whether any component is offered under a separate commercial licence, and the bidder's position on source disclosure for custom code	Decision for the buyer, typically high where legal review of the licence terms is still open
Migration of existing data	Describes how existing datasets, resources, organizations and metadata will be inventoried, mapped and loaded, including how DataStore tables and file resources are handled and how links are preserved	Sample migration plan for a past or illustrative project, a field mapping for the buyer's current catalog, and a test plan with reconciliation counts	Decision for the buyer, based on the number of legacy catalogs and the age of their metadata
Hosting and data location	Places the portal in the buyer's cloud account, data center or air-gapped network, with named data locations for backups and logs and a clear split of duties between the buyer and the bidder	Hosting architecture diagram, data flow and backup location statement, and the list of sub-processors or third-party services that touch data	Decision for the buyer, often high where residency or sovereignty rules apply
Security evidence	Describes hardening of the CKAN, PostgreSQL, Solr and Redis tiers, access control for the DataStore read-only role, vulnerability management and how findings are reported	Recent security test report scope and summary, patching records, hardening baseline, and a description of how control evidence is produced for assessors	Decision for the buyer, based on the classification of the data the portal publishes and any restricted datasets
Accessibility and metadata	Commits to the accessibility standard the buyer must meet and explains how the portal theme, forms and dataset pages are tested, plus metadata mapping to the required profile such as DCAT-AP through ckanext-dcat	Accessibility test approach and sample results for a comparable site, sample RDF output, and validation steps for the metadata profile	Decision for the buyer, typically high where the law sets a dated accessibility obligation
Support after go-live	Sets out what is covered after launch, including security patches, upgrades, incident response hours, and who answers for DataStore loads through XLoader	Written support schedule, escalation path, sample incident record, and the terms for retainers or renewals	Decision for the buyer, based on internal staff capacity to run the portal
Scope definition	Lists deliverables, acceptance criteria, exclusions and change control in a written fixed scope, with dates tied to milestones rather than open-ended effort	Draft statement of work, acceptance test plan, change request template and a sample of how scope changes were priced in a past project	Decision for the buyer, typically high where budget approval depends on a fixed scope

What do buyers ask before hiring outside help with CKAN?

Effort and cost follow the written scope, not a general figure. The main drivers are the number of datasets and resources, which extensions are in play (for example, DCAT harvesting or SAML single sign-on through an extension such as ckanext-saml2auth), how much legacy data must be migrated and cleaned, the hosting model, and how much accessibility work the portal needs to meet the standards that apply to it. Each of these moves the cost in a different direction, so ask the bidder to show which driver accounts for which line. DeployOpen does not publish a price list. A quote follows from the scope agreed in writing before work starts, and that scope should list the deliverables, the assumptions behind them and the items excluded. Ask for the duration of the fixed scope to be stated in that document as well, with its start conditions, rather than accepted as a general estimate.

The buyer has to supply decisions and people, and the proposal should name them. Before a partner starts, the buyer needs named data owners who can confirm what may be published and under which licence, metadata decisions on the core fields and any standard profile the portal must follow, an identity and access model that states who may create, edit and publish datasets, and a sign-off owner for each stage, from the test site to go-live. Delays in these areas are the most common reason a fixed scope runs late, so ask the bidder to list each buyer dependency with the date it is needed. Also confirm who holds the administrator accounts, the server access and the backup responsibilities after handover.

An internal team can deliver some CKAN projects alone, but the proposal should say what skills it needs. Organizations with Linux, PostgreSQL and Python operations experience and a clear owner for metadata can run an installation themselves, using the source install requirements that the CKAN installing from source documentation sets out. Teams without that experience usually need outside help for the search and cache layer, the upgrade path, and security hardening. Ask each bidder to state which tasks their people will do, which the buyer's staff will do, and what knowledge transfer and documentation will remain after go-live.

How DeployOpen scopes, delivers and supports an open data portal

DeployOpen plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For an open data portal, we start from your written RFP answers, agree the scope in writing, and then build and hand over a CKAN deployment that your team can run.

How we scope

Confirm which CKAN edition, extensions and metadata profiles your RFP answers require before any build work begins.
Record hosting location, identity provider, licence obligations and migration sources in a written scope agreed before work starts.
Define deliverables, acceptance tests and timelines in writing, since most engagements are fixed-scope.

How we build

Install and configure CKAN from source with PostgreSQL, Solr, Redis and the DataStore inside your environment.
Load existing datasets, map metadata to your chosen profile and test the DataStore Data API against your sample files.
Run security testing on the portal and its APIs, then document configuration, backup and upgrade procedures.

How we hand over

Deliver the configured portal with runbooks, operating instructions and the evidence your compliance assessors will request.
Train publishing staff and administrators on the workflows, roles and organizations agreed in the scope.
Confirm acceptance against the written criteria before handover, and record any open items with owners and dates.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after go-live, scoped separately from the build.
Plan CKAN patch and minor upgrades with your team, since patch releases and minor releases carry different compatibility risk.
Agree support terms, response expectations and escalation paths in writing before the engagement closes.

Open data portal RFP questions