23 October 2026 · tech-expert.moscow editorial team
First establish exactly what had to be handed over
The term “working database” can mean different things: a table schema, test records, a copy of production data or a configured system instance. Checks therefore begin with the technical specifications, contract annexes, agreed handover procedure and correspondence about the deliverables. A specific benchmark is needed: which data and functions should be available after deployment, for which period and in which environment.
It is useful to list the expected materials and identify the file, link or access actually received for each item. Record the handover date, method of receipt and project version separately. This helps distinguish a missing component from one that cannot be opened or differs from the agreed contents. The mere presence of a folder named backup does not establish that it contains a suitable backup.
Source code, schema and data serve different purposes
Code describes application logic. The database schema defines the storage structure. Migrations change that structure sequentially. Initial data may create user roles, statuses, settings or reference lists. Production records contain information accumulated during operation. These parts are connected, but none replaces another.
For example, migrations may successfully create empty tables, after which the application opens a login page. This does not yet establish that documents, operation history and files have been transferred. The reverse is also possible: data are delivered, but the code version expects different fields. The error then relates to package compatibility and does not necessarily mean the database is missing.
Components to check alongside the database
- Export contents. Schema, records, sequences, required functions and other objects; any restrictions to selected tables or periods.
- Versions. Database management system, extensions, application runtime and recorded source code version.
- Users and permissions. The roles the application needs and the permissions specified in the installation instructions.
- File storage. Uploaded documents, images and other objects referenced by the database.
- Settings and dependencies. Service addresses, task queues, scheduler, search index and requirements for external integrations.
- Instructions. Build, restore, start and verification procedures, and a list of permitted environment parameters.
Secrets and production passwords should not be included in publicly accessible correspondence or published with source code. Agree on secure transfer of the information needed for examination or checks in a controlled environment. If an anonymized copy is used, describe which information has been replaced and whether this could affect the function being checked.
Why the existence of an SQL file does not mean restoration succeeded
Export format and parameters matter. For example, in PostgreSQL, a standard dump of one database does not cover all cluster-wide objects: roles and tablespaces require separate consideration. A schema-only dump contains no user records. Archive size or file extension therefore provides only preliminary information about the handover contents.
Restoration checks must consider logs and whether the operation completed. If the tool continued after errors, some objects may remain unrestored. A running interface also cannot replace data verification. Agree on specific checks in advance: open a particular document, find a record for a known period, perform a calculation or generate a report using the expected source data.
How to perform checks while preserving original materials
- Preserve the received package in its original form, inventory the files and record the circumstances of receipt.
- Create a separate working copy for examination. Do not use it to replace the live production system.
- Record the test environment's characteristics and compare them with the project requirements.
- Check the restoration instructions, errors, warnings and objects actually created.
- Run the agreed scenarios and record the results of each step, including the data entered.
- List separately any actions taken to correct or supplement the package and check their effect on the result.
Before running unknown installation scripts and dumps, their contents and a safe execution method require technical assessment. Restoration is performed in a dedicated environment with restricted access. This also distinguishes the properties of the delivered package from the characteristics of a live server, where changes may already have accumulated since handover.
How to describe discrepancies found
Instead of a general comment that “the database does not work”, prepare a table showing the expected function, initial condition, material checked, action sequence, actual result and supporting log. If attachments do not open, check the database records and the corresponding files, their paths and access permissions. If history is missing, establish the period covered by the provided copy.
Each conclusion is tied to a specific version of the materials. Successful startup after adding new files does not automatically demonstrate that the original package was complete. Equally, failure on an unsuitable server version does not by itself establish a defect in the delivered code. The examination must make clear the conditions under which the result occurs.
Materials to prepare for the expert
Provide the technical specifications, handover inventory, source code archive or agreed repository access, the database copy received, instructions and error messages. Attach a list of scenarios that worked previously or are required by the specifications, stating the supporting evidence. If the old server remains accessible, agree in advance on how its condition will be recorded.
Checksums help verify that files remain unchanged between storage and examination stages. On their own, they do not establish authorship, creation date or contractual compliance of the package. A technical examination can establish its contents, compatibility and reproducible operation from the materials provided; contractual consequences require a separate assessment of the documents and circumstances of the dispute.
Questions for examination
- Which software components and data are included in the delivered package, and which materials are missing for checking the agreed functions?
- Are the source code version, database schema and supplied data compatible with each other?
- Can the system be deployed using the supplied instructions in the environment specified by the technical specifications?
- Which specific errors occur during restoration and the test scenarios, and what are their technical causes?
- Which additional components or actions are required to reproduce the specified functions?