It is difficult to understand the requirement as specified, so first I will try to show where additional explanation may be needed.
You have tagged this post with "Migration", so I assume these programs already exist and are known to work on some non-Linux architecture. The concepts of inter-process communication and signalling are fairly universal, but stating the architecture and OS the programs presently run on would be very helpful.
I also see the tag "multithreading" although the text only mentions two distinct processes. Does either of the programs actually multithread?
I initially considered that "front" and "back" related to a foreground and background process started by a shell (also tagged). But that is not a true relationship between the processes themselves, only their relationship with their launching mechanism.
I believe you are referring to a "front-end" program that provides a GUI for the entry of parameters, and once these are passed to the "back-end" program it proceeds autonomously. It is also possible that the front-end may need to only be suspended, until the GUI can be used again to provide feedback or results.
A key question is the communication of parameters between the two programs. The methods I am aware of include: shared memory; piped streams (as unnamed pipes, named pipes, or sockets); and shared files. Signals are only suitable for events, not for data flows. The existing mechanism has to be understood so we can proceed.
It is not possible for a program to "take control" of another. There may exist a parent-child relationship (and either your front-end or back-end could be the parent), but the relationship cannot be reversed. The function of the parent is to pre-arrange the communication between parent and child: alternatively, the parent may launch two children (siblings) that can communicate with each other.
Either parent or child can signal the other, and in fact each signal can kill the other process. It is more usual to end the relationship by closing the channels of communication between them, which gives the ending program the capability of a tidy closedown.
If you already have these programs, it would be very helpful to know exactly how they interact at present, so that the closest match of Linux features can be recommended. There is no purpose in my suggesting a model that requires major changes in the existing code, when another approach could be a far better fit.
It is almost certain that Linux can provide the necessary environment for these programs to co-operate. The issue is that we still know nothing about the existing mechanisms that would need to be emulated, or indeed whether you have access to the source of the programs, and what language they are written in.