While there is some tiny overlapping region Docker and the Debian packaging systems essentially solve two very different problems:
The Debian packaging system is built to install software on a host and upgrade it as easily as possible. It is able to handle complex dependency and constraint patterns between software components, like “software X version A requires software Y with version B or newer installed” or “software X should never be installed with software Z version C”.
The Docker system is conceived to easily describe and deploy services, especially micro-services, possibly on several hosts – e.g. a Docker swarm or a Kubernetes cluster.
These two problems are essentially orthogonal, which means that given the deployment problem to solve, one can use one of them, both of them, or maybe even none of them, as part of the solution. When using both of them, the Debian package is used in the production of the Docker image, and your Dockerfile (the recipes used to prepare the Docker image describing the “virtualised system” ran in a container) would essentially register your Debian repository in the sources of the Debian packaging system and install your package.
With this in mind, it seems to me that what you are really looking for is to implement the immutable server pattern. The recent development in cloud technologies made possible to upgrade software not by using the classical software upgrade system from a software package system (such as the Debian packaging system) but rather by simply replacing the full server at once. (Some persons did this before this development by having three OS-s on a server, two used in alternance to run the appliance and a mini-OS dedicated to performing the appliance replacement. While not overly complex, this seems to have always remained a niche.) This technique can be of interest for you because if you are used to upgrade software on your server using the package manager, the final state of the server depends of the “upgrade history” of the server – especially if errors occur in the upgrade process. This heterogeneity is bad, because it makes production problems hard to reproduce and diagnose, and your mixed experience
We have thousands of these boxes out on the field. We manage the package dependencies, process registration, etc. through a deb package with varying degrees of success.
could relate to this. The immutable server pattern wipes this source of errors by essentially destroying the notion of “upgrade history” from the problem.
Now there are various options to implement the immutable server pattern, two popular choices are to use Docker images, images or to use “master instance images” from your cloud provider (these are called AMIs in AWS and just Custom Images in Google Compute Engine). Your use-case forbids the use of cloud based techniques, I will therefore assume Docker images as the only eligible choice. (For the sake of completion, it is certainly possible to use other approaches, for instance using Virtual Box or similar virtualisation solution, as an alternative to Docker.)
When using the immutable server pattern technique, you introduce a new artefact (the Docker image) representing your server and this artefact can be tested as well, and it is very easy to obtain a setup replicating truthfully your production settings – aside from service load.
Now to consider the concrete problem you described, let's assume implementing the immutable server pattern with Docker is actually what you want. Since the Docker system and the Debian packaging system are complementary rather than mutually exclusive (cf. intro) we still have to address the question if you should you prepare a Debian package for your software.
The pertinence of using a Debian package to install your software (in the Docker image or on a host) lies in the complexity of the versioning problem you have to solve. If you run at the same time several versions of your software, occasionally need to downgrade, and have complex version requirements that you need to carefully document, having a Debian package is a must-be. Otherwise, this step can be skipped – but since you already put an effort to produce and deploy these packages, there is no real value into ditching your work. I would therefore suggest continue to produce your Debian packages.